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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.