Parsing errno.h for error codes.

[wilx]

For the work on Linux extended file attributes support I needed few standard error codes. I looked them up manually but I was curious if it were possible to do it automatically. I have come up with what is committed in repository https://github.com/wilx/parse-linux-libc-error-codes. I am just offering it as a POC of something that might be useful to JNA project to generate a list of error codes.

[dbwiddis]

This can be closed as ErrNo class was committed in #1202

[Nadahar]

Except for the fact that the errno integer values aren't always the same. For example is EAGAIN 11 on Linux and 35 on macOS.

http://www.ioplex.com/~miallen/errcmp.html
https://stackoverflow.com/questions/35095560/do-errno-values-differ-across-nix-systems

[dbwiddis]

Fair point as it seems BSD-derived systems differ from Linux. However, this specific Issue mentioned Linux, and the mapped headers are in the Linux platform mappings.

More generally, this issue suggests run-time parsing of a .h file in the filesystem and I suspect the the location of errno.h is much less predictable than the values which can be separately mapped per-operating-system, so I still think leaving it closed is justified.

[Nadahar]

I agree that the parsing of the header files doesn't really look viable - I just came over this while trying to find a way to get the correct integer values for the different platforms. I don't see any easy way to do that though, so I just I will just have to hard-code the only the error codes I need and use the Platform tests to set the values.

I know too little about how the JNI part works, but maybe it would be possible to "capture" the error codes in jnidispatch and let JNA retrieve them from there?

[dbwiddis]

I will just have to hard-code the only the error codes I need ...

A reasonable approach.

I know too little about how the JNI part works, but maybe it would be possible to "capture" the error codes in jnidispatch and let JNA retrieve them from there?

In general, faithfully reporting the numeric error code to the user is all that is needed. In predictable situations in widely used operating systems it is reasonable to make a best effort attempt to translate the numeric code to a meaningful value. Windows provides an actual API (FormatMessage) to give a textual response.

However, the constant names in the errno.h headers on *nix are internal names/implementation details that may ease developers using JNA in writing code without defining these constants themselves, but are not visible to users. A textual description appears to be available with strerror(). JNA does use strerror_r in its native code for lower level faults.

It seems reasonable to try to map that (or perror()) at a higher level in preference to parsing a header file, and a PR would be welcome should you want to go that route.

[Nadahar]

I agree that strerror() (and potentially perror()) should suffice for producing error messages. I have already mapped strerror() in my "NixCLib" interface.

The use I'm after is different, it is using these constants for evaluation in the code itself. This might not be very relevant for many of the errors, I don't know enough about many of them. In my case, EAGAIN is what has turned out to be a problem this far. I'm doing some non-blocking FIFO/named pipe work, and I must use errno responses as a part of the "program flow". In the man pages for the commands I've been using this far (mkfifo(), open(), read(), write() etc) they list different "errno constants" that can be expected under different circumstances, and you need to use these to decide what to do next (read/write again, try to reconnect, give up and report error etc). For this to work, I must be able to use the correct integer value for the platform when evaluating to make the correct decisions. For all I know, EAGAIN is the only error where this is a relevant problem, but for EAGAIN it very much is - as it's the code for "try again" when using non-blocking I/O.

POSIX only defines the names of the constants and defines that they should have a positive int value. What value is up to the implementation, and that decision is the core of this whole somewhat bizarre situation. It might be a really uncommon problem, but it's easy to see how people can end up in the same trap when they find ErrNo, even if it is defined under Linux only.

I would normally gladly make a PR for strerror(), but there are two reasons why I'm not tempted. 1) It would need to be properly tested on all relevant platforms, I don't have access to all of them. 2) I'm stuck at JNA 4.4.0 because we still support Windows XP, so I'm not actually familiar with or use the more recent versions of JNA.