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

[Alexandre Oliva <oliva@adacore.com>]

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

> It defines a new _At_path type which contains a {fd, path} pair (to be
> used together by openat and unlinkat) and a separate path to be used
> on its own. This allows identifying a file within a directory
> unambiguously, without being concerned with whether HAVE_OPENAT and
> HAVE_UNLINKAT are defined.

> With this change I don't think your patch to make dir_and_pathname()
> check HAVE_OPENAT is needed.

*nod*, I've amended your patch in my local tree to reverse them both.

> This passes tests on x86_64-linux.

Have you by any chance tried it while forcing libstdc++ not to use
openat?

I'm debugging 27_io/.../copy.cc on rtems with a fixed remove_all (there
were bugs in the previous version I posted), and hitting an exception
within the very first call of dir.__erase() in the remove_all at the end
of test_pr99290, after an attempt to open "source" fails.  It looks like
the atp.pathname is missing the nonexistent_path assigned to variable
dir in test_pr99290, so we attempt to open subdirs thereof as if with
openat.

-- 
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>