On Mon, Dec 13, 2021 at 3:10 PM Grant Seltzer Richman
<grantseltzer@xxxxxxxxx> wrote:
>
> I'm using libbpf and want to make sure I'm properly handling errors.
>
> I see that some functions (such as `bpf_map_batch_common`) return
> error codes using `libbpf_err_errno()`. My understanding is that since
> libbpf_err_errno() returns -errno, these function calls can just be
> followed by checking the returned error code.
>
> Some functions (such as `bpf_map__pin`) return `libbpf_err(int ret)`
> which sets errno and returns the error code. In this case, does errno
> even need to be checked?
>
No it doesn't, checking directly returned error is enough. We set
errno always for consistency with APIs that return pointers (like
bpf_object__open_file(), for example). For the latter, on error NULL
is going to be returned (in libbpf 1.0 mode), so the only way to get
details about what failed is through errno.
so doing:
if (some_libbpf_api_with_error_return(...)) {
/* errno contains error */
}
is the same as
err = some_libbpf_api_with_error_return(...);
if (err < 0) {
}
But you only can use:
ptr = some_libbpf_api_returning_ptr(...);
if (!ptr) { /* errno has error */ }
I plan to remove libbpf_get_error() in libbpf 1.0, btw. The pattern
above will be the only one that could be used.
> Why the inconsistency? I'd like to document this, so anything else
> that you can add on error handling in libbpf is welcome. That includes
> example usage.
>
> Thanks!
