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:55, Sebastian Huber wrote: > 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. Ok, ACK. Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat
signature.asc
(application/pgp-signature, 833 B)
-----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAlu9/MkACgkQ9TYGna5E T6AFeA//bnnD0q8NTjneziuQjVaA30eEwTugazncFZ4nKvc9zaGw9GEltZNYLNLF s6f+TieTVOmGCTcs/v8gbLoLb+9nHbaIHqyt9WWzz1P1wVPWSA6z+fzvZZ4IE85l QASkt82ZLXeZ8LL96ZH3dT79gqZIIguYJed0xWde+PG6+6WPo6q0rCY5wxEsji8Q pfgbCfkWVKt4XZP11fxkHcNuQWrmaYwM0GShxV6aGGFUlQ04Z3EJN7eIyK6miHkN LK/YT9rWerOO/kOwH1Se1ZjJHkAK9wO0EHTsxnHWpU19iEyArAhxice6pn4mJ/Dh NTgPgAzjTRDyssFCOq6IxrzSk6CkoUK/Jna/rmX1qeaXJ10+uTXetmQZFPKUA1fa 4Bf4AVyYfGDpwGMg7cjgnEcsTc0uNrMcOsENkv8t0ULG7yPYuNfuOJPzRXtnpaVu Id6ZqYLqYKJCXDOWphoXZmk4OH9W9kvUW5MkauAeByQ4b4mY6Lwax2DeBv+81mr9 /A0cF33MX0Nslf4nh7rd2Xl2t0q2xfw58RBuVjxRRPQVfk/kM8HvSTLmzXQjVmtT fKAwkdcOi9G1/7ErpWyvAnBEHGX5HLio4gxrtLCwWF4HsdDbBlZFiUMe8ZR8Y71U QdauS3W4BsYrWe3piIcAiKIHQ7CqQ0Q9ZbFmyjBXKL0S0SL/ri8= =3atE -----END PGP SIGNATURE-----