On Thu, 23 Jun 2022 at 15:05, Alexandre Oliva wrote: > > On Jun 23, 2022, Jonathan Wakely wrote: > > > On Thu, 23 Jun 2022 at 12:08, Alexandre Oliva wrote: > >> > >> On Jun 22, 2022, Jonathan Wakely wrote: > >> > >> > There are other interactions between AT_CDCWD and ::openat not covered > >> > by this patch. I this this also needs to check HAVE_OPENAT: > >> > >> Here's an updated version, tested with this additional change. > > > Did this improve your test results for directory iterators? > > 'fraid the bad results I posted earlier today had this patch in. I > can't tell whether it improved anything because I didn't save earlier > results to compare. > > > In the unlikely even that the target has ::unlinkat but not ::openat > > c++config.h on the target says: > > /* #undef _GLIBCXX_HAVE_UNLINKAT */ > > Thanks for the concern, Here's what I'm thinking of so that the derived _Dir class doesn't need to know whether the base _Dir_base::openat function will actually use ::openat or not. 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. This passes tests on x86_64-linux.