[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