On Jun 22, 2022, Jonathan Wakely <jwak...@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>
