Re: [PATCH 2/6] Open a directory with the usual flags
Corinna Vinschen <[email protected]>
| Newsgroups | gmane.comp.lib.newlib |
|---|---|
| Message-ID | <[email protected]> |
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? Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat
signature.asc
(application/pgp-signature, 833 B)
-----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAlu95BUACgkQ9TYGna5E T6By4A//Ro6T+8+SPMLYxuC5DbwCzYNP7r9vTUXMOhDjmYBrICsK0/WoITM9haPI wjydzyukszTfRV4OE8tn35fZV2az+eVIgo1h8RrVPFii6v/c3AZK6aJFiMJhzk8D Yj9B9+0DBYocuxhNuS0VnpFuT3wIYSBKzFu86McVJxNBtPuK+RxHwmx62/Nnt5Jc FqIF92s127h5fGjgL+SJmftzi6pZXG2lLkoClt8jlhLiURwy+xNUWEPIjQD+LNNN G6ORzOpOgRGnhR648fThQ3bI4D0JEdLUlDIj2a1/O6xynKuey4cUBSdvuSOCoJ55 3v+NshGjDlmTld0cYfpqFNyyQr/zb83KkNMQa3U6zoMAlhQvV0EvOTmLdn8F9GGB wzYRELHRCG66DgqzXgUQFqNj/NtxCIJdgB8ktG9yC1EwLt6VqhDyel/XcykCgBcS +k81VsHnCue5wBKjBZkD9KOnnGMSgeNSr1SF/VUkmtifhDqdEwpEfNM4kT5v+Q81 RkQWZAG3uFs5yFvjM1JEC+Ziut0UPnu9o9JMwrWf+g/g/YUmEBq1ZY+LB4iJaPOd 5BgK/6GnmLDtfKSv7szZuo3NxDqVIl5GzcoUK6xQdpMziPhO6QbBzUXtsmuu0VWz GbfmCE0Jk0mJueO5WMbchhUBAfyE0QO8CQmX+hiFmRmSMPHZkRo= =H23d -----END PGP SIGNATURE-----