| |
| |
I redact, please ignore last 2 correspondences. If you go the macro route,
I will just modify platform.H to define it for specific compilers.
SIDE NOTE: I am still in disagreement with you on your interpretation of
ENOENT for readdire
On Wed, Jun 16, 2021 at 2:19 PM Mark Olesen ***@***.***> wrote:
> C:\temp>gcc -dM -E t.c |grep DOS
> #define DOSERROR_STR _DOSERROR_STR
> #define DOSERROR _DOSERROR
> *#define __MSDOS__ 1*
> #define MSDOS 1
> #define __MSDOS 1
>
>
>
> On Wed, Jun 16, 2021 at 2:10 PM Mark Olesen ***@***.***> wrote:
>
>> If I do a search on "readdir ENOENT" there are some java references that
>> pop, which check for this condition as well. I guess the only way to really
>> find out is to reach out to kernel developers for various operating systems?
>>
>> SIDE NOTE: Various compilers use different macros to specify DOS.
>> OpenWatcom uses '__DOS__'
>>
>> I believe __DOS__ is also used in DJ Delories gcc/g++ implementation
>> (it's been awhile so I am being lazy and not confirming).
>>
>> MSDOS <http://en.wikipedia.org/wiki/MS-DOS>
>> Type Macro
>> Identification MSDOS
>> Identification __MSDOS__
>> Identification _MSDOS
>> Identification __DOS__
>> https://sourceforge.net/p/predef/wiki/OperatingSystems/
>>
>>
>>
>> On Wed, Jun 16, 2021 at 1:49 PM Albrecht Schlosser <
>> ***@***.***> wrote:
>>
>>> Looking at the GNU implementation of readdir, it seems evident that
>>> ENOENT
>>> should be checked for correctness as an EOF condition.
>>>
>>> No, Mark, that's not true. Please *do not take the ENOENT error
>>> condition literally*. In the example code you posted (a link to) this
>>> is the error code returned by the system (kernel) function getdents()
>>> which in this case is turned into an EOF (end of directory) condition for
>>> whatever reason (doesn't matter). This is a special case on "some systems"
>>> (citation) and has absolutely nothing to do with our case here on DOS.
>>>
>>> We do not know why the DOS function readdir() returns ENOENT at the end
>>> of the directory. Maybe this is ancient history and has never been changed
>>> for backwards compatibility. You can't conclude from the (likely Linux
>>> kernel) implementation of getdents() on the result of the DOS function
>>> readdir(). The ENOENT errno value of POSIX readdir() is definitely an
>>> error condition and not just "end of directory".
>>>
>>> The question we need to answer is how we deal with this condition. An
>>> easy (pseudo code) solution would be, partly as Greg suggested, using #ifdef
>>> MSDOS for the decision:
>>>
>>> #ifdef MSDOS /* MSDOS readdir() returns ENOENT on end of directory */
>>> if ((!errno) || (ENOENT == errno))
>>> #else /* POSIX compliant readdir()
>>> if (!errno)
>>> #endif
>>>
>>> ... or something like this ...
>>>
>>> —
>>> You are receiving this because you were mentioned.
>>> Reply to this email directly, view it on GitHub
>>> <https://github.com/fltk/fltk/issues/238#issuecomment-862666320>, or
>>> unsubscribe
>>> <https://github.com/notifications/unsubscribe-auth/AA6DEU4DX5GWBSAVY7UHLSLTTD533ANCNFSM46WEVEKA>
>>> .
>>>
>>
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.![]()
[ Direct Link to Message ] | |
|
| |
