mapping two errno codes (ENOBUFS, ENOMEM) to one NL error code (NLE_NOMEM)

[Karry]

Hi.

I have question, why two different errno codes are mapped to single libnl error code? There is no possibility to distinguish between ENOBUFS (that is not fatal for us) and ENOMEM. Both are mapped to NLE_NOMEM code: https://github.com/thom311/libnl/blob/master/lib/error.c#L103

In our experiments, we found out that we can't rely on errno after some libnl calls when it is compiled with Musl libc - some internal Musl/libc functions setup errno to 38 (Function not implemented) sometimes...

[thom311]

I agree this mapping is a problem.

I think it's not great, that the integer range of libnl errors overlaps with errno, and that some errno are coerced to libnl errors.

I think all operations that fail, should also try to preserve the errno that cause the failure. In your case, what's the callstack from entry into libnl to where the errno was received?

[Karry]

To be honest, I don't know. Libnl entry was nl_recvmsgs_default, it fails with return code NLE_NOMEM (5) and errno ENOSYS (38 - Function not implemented). This is everything that we known from our logs. This failure is not reproducible...