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