On Thu, 23 Jun 2022 at 05:41, Alexandre Oliva <ol...@adacore.com> wrote:
>
> 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.
Yes, that's what I was thinking too.
> 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?
I don't think that quite works. I think what we want is more like:
struct multipath /* need better name */
{
int fd;
const char* filename;
const char* pathname;
};
I already prototyped something like this, let me finish it off and
send the patch.
