[PATCH] Cygwin: Map ERROR_NO_SUCH_DEVICE and ERROR_MEDIA_CHANGED to ENODEV

[Christian Franke]

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