Re: [PATCH 2/6] Open a directory with the usual flags
Sebastian Huber <[email protected]>
| Newsgroups | gmane.comp.lib.newlib |
|---|---|
| Message-ID | <[email protected]> |
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 : [email protected] PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.