On Tue, 28 Jun 2022 at 13:04, Alexandre Oliva wrote:
>
> On Jun 28, 2022, Jonathan Wakely wrote:
>
> > I'll push this today.
>
> Thanks!
>
> > You can just use --enable-libstdcxx-debug
>
> Thanks again ;-)
>
> > Again, that test is *supposed* to return without creating the
> > destination. It's t
On Jun 28, 2022, Jonathan Wakely wrote:
> I'll push this today.
Thanks!
> You can just use --enable-libstdcxx-debug
Thanks again ;-)
> Again, that test is *supposed* to return without creating the
> destination. It's testing the failure case.
Aha, and that's why one shouldn't debug something
On Mon, 27 Jun 2022 at 23:04, Alexandre Oliva via Libstdc++
wrote:
>
> On Jun 27, 2022, Jonathan Wakely wrote:
>
> > -#if _GLIBCXX_HAVE_DIRFD
> > +#if _GLIBCXX_HAVE_DIRFD && _GLIBCXX_HAVE_OPENAT && _GLIBCXX_HAVE_UNLINKAT
I'll push this today.
> Thanks, I had this bit in the WIP _At_path patch,
On Jun 27, 2022, Jonathan Wakely wrote:
> -#if _GLIBCXX_HAVE_DIRFD
> +#if _GLIBCXX_HAVE_DIRFD && _GLIBCXX_HAVE_OPENAT && _GLIBCXX_HAVE_UNLINKAT
Thanks, I had this bit in the WIP _At_path patch, as well as my updated
remove_all patch, in the latest round of tests.
I confirm that I don't get any
On Mon, 27 Jun 2022 at 15:00, Jonathan Wakely wrote:
>
> On Mon, 27 Jun 2022 at 14:32, Jonathan Wakely wrote:
> >
> > On Mon, 27 Jun 2022 at 14:05, Alexandre Oliva wrote:
> > >
> > > On Jun 27, 2022, Alexandre Oliva wrote:
> > >
> > > > It looks like the atp.pathname is missing the nonexistent_
On Mon, 27 Jun 2022 at 14:32, Jonathan Wakely wrote:
>
> On Mon, 27 Jun 2022 at 14:05, Alexandre Oliva wrote:
> >
> > On Jun 27, 2022, Alexandre Oliva wrote:
> >
> > > It looks like the atp.pathname is missing the nonexistent_path
> > > assigned to variable dir in test_pr99290, so we attempt to
On Mon, 27 Jun 2022 at 14:05, Alexandre Oliva wrote:
>
> On Jun 27, 2022, Alexandre Oliva wrote:
>
> > 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.
>
> This appears to be c
On Jun 27, 2022, Alexandre Oliva wrote:
> 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.
This appears to be caused by the early return in fs::_Dir's ctor:
_Dir(const fs::path
On Jun 23, 2022, Jonathan Wakely 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 whe
On Mon, 27 Jun 2022 at 10:49, Alexandre Oliva wrote:
>
> On Jun 24, 2022, Jonathan Wakely wrote:
>
> > Ah, but this patch only added the HAVE_OPENAT check to
> > src/filesystem/dir.cc not the similar code in src/c++17/fs_dir.cc
>
> Doh! It was such a long and goof-ful day :-(
>
> Thanks for catc
On Jun 24, 2022, Jonathan Wakely wrote:
> Ah, but this patch only added the HAVE_OPENAT check to
> src/filesystem/dir.cc not the similar code in src/c++17/fs_dir.cc
Doh! It was such a long and goof-ful day :-(
Thanks for catching it.
Unless you ask me not to, I'd like to install this to compl
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
> >> >
On Jun 23, 2022, Alexandre Oliva wrote:
> * aclocal.m4, configure, config.h.in: Rebuilt.
Dropped aclocal.m4 for the checkin, thanks to the ChangeLog checker.
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU T
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
> >> >
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:
>>
>> H
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
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.
libstdc++: check for openat
From: Alexandre Oliva
rte
On Thu, 23 Jun 2022 at 05:41, Alexandre Oliva wrote:
>
> On Jun 22, 2022, Jonathan Wakely 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 fi
On Jun 22, 2022, Jonathan Wakely 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 ma
On Wed, 22 Jun 2022 at 07:43, Alexandre Oliva via Libstdc++
wrote:
>
>
> rtems6.0 has fdopendir, and fcntl.h defines AT_FDCWD and declares
> openat, but there's no openat in libc. Adjust dir-common.h to not
> assume ::openat just because of AT_FDCWD.
>
> Regstrapped on x86_64-linux-gnu (detects a
rtems6.0 has fdopendir, and fcntl.h defines AT_FDCWD and declares
openat, but there's no openat in libc. Adjust dir-common.h to not
assume ::openat just because of AT_FDCWD.
Regstrapped on x86_64-linux-gnu (detects and still uses openat), also
tested with a cross to aarch64-rtems6 (detects open
21 matches
Mail list logo
