[PATCH 2/6] Open a directory with the usual flags

Sebastian Huber sebastian.huber@embedded-brains.de
Wed Oct 10 13:21:00 GMT 2018


On 10/10/2018 13:35, Corinna Vinschen wrote:
> On Oct 10 13:16, Sebastian Huber wrote:
>> On 10/10/2018 11:50, Corinna Vinschen wrote:
>>> On Oct  8 15:38, Sebastian Huber wrote:
>>>> Use O_RDONLY since you are not supposed to write to a directory.
>>>>
>>>> Use O_DIRECTORY as mandated by POSIX (The Open Group Base Specifications
>>>> Issue 7, 2018 edition IEEE Std 1003.1-2017):
>>>>
>>>> "If the type DIR is implemented using a file descriptor, the descriptor
>>>> shall be obtained as if the O_DIRECTORY flag was passed to open()."
>>>>
>>>> Use O_CLOEXEC as mandated by POSIX:
>>>>
>>>> "When a file descriptor is used to implement the directory stream, it
>>>> behaves as if the FD_CLOEXEC had been set for the file descriptor."
>>>>
>>>> Drop the fcntl() call in favour of O_CLOEXEC.
>>> Yeah, that really makes sense, but what about targets not (yet)
>>> implementing O_CLOEXEC???  I'm not sure how to handle this, if
>>> we have to handle that at all.
>> In RTEMS there are no processes (fork(), exec(), etc. don't work). So, it is
>> trivial to support the O_CLOEXEC. The situation in which this flag is
>> relevant simply cannot happen.
>>
>> Are Cygwin and Linux the only Newlib systems which supports processes?
> I really don't know, but the other problem is to use a flag in a target
> dependent call which might be unsupported, but tested.  This is backed
> by POSIX allowing open to return EINVAL for invalid flags.
>
> We should probably define _FNOINHERIT only on targets known to support
> it (even if trivially) and to call open(O_CLOEXEC) or fcntl() depending
> on that test, no?

POSIX says there is an O_CLOEXEC, so I think this is a valid oflag 
value. An unsupported close on execute would be more an ENOSYS which is 
not mentioned in the error list:

http://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html

I would define the POSIX flags unconditionally and in case errors show 
up on a particular system, then we can find a solution, e.g. not define 
it on system X.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber@embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.



More information about the Newlib mailing list