Corinna Vinschen wrote:
On Feb 25 10:12, Christian Franke wrote:
Corinna Vinschen wrote:
So the default was EPERM at first and has been changed to EACCES
because it "is better for the unknown error case".
I'm open to ideas for an improved error mapping.
I have no better suggestion for a default errno. Adding a cygwin specific
one (like ENMFILE, ENOSHARE and ECASECLASH added 2000-2001) is possibly not
desired.
ENOSHARE and ECASECLASH are not used anymore, fortunately, and ENMFILE
is hopefully never returned to userspace. It might be a good idea to
remove it from Cygwin's code as well.
Some thoughts about minor improvements of the errmap.h file:
- Add error number to each /* ERROR_... */ comment, e.g. /* 2:
ERROR_FILE_NOT_FOUND */.
Ok.
- Update /* NUMBER */ comments using current MinGW-w64's winerror.h (~850
changes).
Why so many? I used winerror.h to populate the list not too long ago,
so I wonder why it suddenly has so many more error codes?
"Required for mozilla-central." - 850 insertions:
https://sourceforge.net/p/mingw-w64/mingw-w64/ci/ddeb05a
Most or all would possible never occur with the NTDLL/Win32 API subset
used by Cygwin.
Includes interesting codes like "ERROR_NO_WORK_DONE" :-)
- Max errno is 143, so data type size could be reduced from int to uint8_t
aka unsigned char. Could even add a compile time check by using C++11's
braced initializers which do not allow narrowing conversions.
Yeah, we could do that.
- Remove trailing entries which only map to 0.
- Append a static_assert which checks whether array size matches the last
mapped error number.
Yeah, not so sure about that. I'm aware that we only map errors
below 3000 somewhere, but it's no safe bet that it stays that way.
For instance, we handle NT status codes STATUS_TRANSACTIONAL_CONFLICT
and STATUS_TRANSACTION_NOT_ENLISTED and those translate into the TxF
error range between 6800 and 6899. We don't convert those to userspace
errno yet, but consider having to add them at one point and thus having
to add the 3000 entries from the last used one up the newly used one.
The reason to keep them is to allow us to be lazy about it. The list
also just takes ~36K, and with the change to uint8_t it only takes
9K, so what?
Ok.
I could provide separate patches if desired.
Always welcome!
Ok.
Thanks,
Christian