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

[Jonathan Wakely <jwakely@redhat.com>]

On Mon, 27 Jun 2022 at 23:04, Alexandre Oliva via Libstdc++
<libstdc++@gcc.gnu.org> wrote:
>
> On Jun 27, 2022, Jonathan Wakely <jwakely@redhat.com> 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, as well as my updated
> remove_all patch, in the latest round of tests.
>
> I confirm that I don't get any errors with it on an x86_64-linux-gnu
> native built with openat and unlinkat forced disabled in libstdc++, but
> on aarch64-rtems6, there are some fails that are not making much sense
> to me.  I haven't looked into any but 27_io/.../copy.cc, so I can't tell
> whether they've regressed, but copy.cc's test01 did when I put this (or
> variants thereof) in.
>
> Tomorrow I'll look into building libstdc++ with -Og or something else
> with less optimization than the default, to help me make sense of what's

You can just use --enable-libstdcxx-debug and then link to the libs in
$libdir/debug instead of $libdir (e.g. with LD_LIBRARY_PATH).

> going on that causes copy() to return without as much as creating the
> destination.

Again, that test is *supposed* to return without creating the
destination. It's testing the failure case.

>
>
> FAILED: default@libstdc++,27_io,filesystem,operations,copy_cc
> FAILED: default@libstdc++,experimental,filesystem,operations,copy_cc
>
> .../27_io/filesystem/operations/copy.cc:5[67]: void test01(): Assertion '!exists(to)' failed.

I don't know what 5[67] means, so I don't know if that's the first or
second !exists(to) assertion, but this is not failing because copy
returned without creating something. copy is not supposed to create
anything here, and it didn't, because the previous assertion (ec ==
std::make_error_code(std::errc::is_a_directory)) didn't fail. So the
copy function behaves correctly, but the 'to' file exists anyway.
Which suggests to me another problem with mkstemp / nonexistent_path.
Before rebuilding the library I'd just add an extra assertion into the
test.

--- a/libstdc++-v3/testsuite/27_io/filesystem/operations/copy.cc
+++ b/libstdc++-v3/testsuite/27_io/filesystem/operations/copy.cc
@@ -49,6 +49,7 @@ test01()
  VERIFY( ec );

  auto to = __gnu_test::nonexistent_path();
+  VERIFY( !exists(to) );
  ec.clear();
  auto opts = fs::copy_options::create_symlinks;
  fs::copy("/", to, opts, ec);

I suspect this is going to fail, because 'to' already exists before
you ever call copy("/", to, opts, ec).

And that would happen is nonexistent_path is still broken. Do you have
the commit r13-1289-g30a8f67295f412 in your tree?

> FAILED: default@libstdc++,27_io,filesystem,operations,copy_file_cc
> FAILED: default@libstdc++,experimental,filesystem,operations,copy_file_cc
>
> terminate called after throwing an instance of 'std::filesystem::__cxx11::filesystem_error'
>   what():  filesystem error: cannot copy file: File exists [filesystem-test.000001-copy_file] [filesystem-test.000001-copy_file]

Again, this looks like a problem with nonexistent_path, the 'from' and
'to' paths are the same:

  auto from = __gnu_test::nonexistent_path();
  auto to = __gnu_test::nonexistent_path();


> FAILED: default@libstdc++,27_io,filesystem,operations,equivalent_cc
> FAILED: default@libstdc++,experimental,filesystem,operations,equivalent_cc
>
> .../27_io/filesystem/operations/equivalent.cc:4[45]: void test01(): Assertion '!result' failed.

This would also happen if nonexistent_path still returns the same value twice.

>
> FAILED: default@libstdc++,27_io,filesystem,operations,relative_cc
>
> .../27_io/filesystem/operations/relative.cc:32: void test01(): Assertion 'r == ".."/p' failed.

Ditto.

>
> Also still present:
>
> .../20_util/from_chars/4.cc:304: error: 'log2' is not a member of 'std'; did you mean 'log'?
>
> (IIRC we used to have two of these, we're now down to one)

That should be fixed at r13-1315-g30aea28bd30027 now.