Re: [PATCH] libstdc++-v3: check for openat

[Alexandre Oliva <oliva@adacore.com>]

On Jun 22, 2022, Jonathan Wakely <jwakely@redhat.com> wrote:

> Otherwise, if rterms defines HAVE_DIRFD this function will return a
> file descriptor and a filename (not a full path) but then
> _Dir_base::openat doesn't use ::openat and so ignores the file
> descriptor, and needs a full path.

Yuck.  It does.  This may explain some of the fails I've observed and
not looked into yet.


How about introducing an internal wrapper class that can hold a ref to
base path or an fd for a dir, or an iterator that could resolve to
either, and that can be passed around instead of a dirfd that assumes
openat, enabling uses of openat where available and falling back to
paths otherwise?  I don't have much of a sense of all the uses involved,
but given the AFAICT impossibility of turning a dirfd into a pathname
(even in non-pathological cases of removed or out-of-chroot dirfds),
ISTM this wrapper class could demand base paths or CWD in the
!HAVE_OPENAT case, and enable both uses otherwise, offering some
additional type safety that the current abstraction doesn't.

Does that make sense to you?

-- 
Alexandre Oliva, happy hacker                https://FSFLA.org/blogs/lxo/
   Free Software Activist                       GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>