| |
| |
Okay, lets take a moment and hold off on a decision. I e-mailed GLIBC list
and will wait for a response. Hopefully, then can clarify the meaning of
ENOENT for readdir
On Wed, Jun 16, 2021 at 2:29 PM Mark Olesen ***@***.***> wrote:
> 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 ] | |
|
| |
