Hence you don't specify it. If stat'ing or <insert function name here> returns the same information for what are different files, then <insert function name here> is not the way to distinguish different files. Submit a bug report and fix that implementation for that platform.


From: Std-Proposals <std-proposals-bounces@lists.isocpp.org> on behalf of Thiago Macieira via Std-Proposals <std-proposals@lists.isocpp.org>
Sent: Sunday, September 1, 2024 6:44:13 PM
To: std-proposals@lists.isocpp.org <std-proposals@lists.isocpp.org>; Jeremy Rifkin <rifkin.jer@gmail.com>
Cc: Thiago Macieira <thiago@macieira.org>
Subject: Re: [std-proposals] Revising #pragma once

On Sunday 1 September 2024 09:17:05 GMT-7 Jeremy Rifkin wrote:
> I agree. Much of the point of standardizing would be providing
> guarantees about what "same file" means.
>
> For wording, one option is to borrow some wording from
> std::filesystem::equivalent

And again, as Tom's report showed but he didn't highlight,
std::filesystem::equivalent will come to different conclusions too.

The MS STL implementation uses GetFileInformationByHandleEx(), so it can
compare the 128-bit unique identifier. The libstdc++v3  and libcxx
implementations use GetFileInformationByHandle(), so they suffer from the same
problem as Coverity did.  And then you have Cygwin, whose source of stat() I
can't find, but is used to supply the builds of GCC, so GCC's fs::equivalent
will be the Unix implementation through Cygwin, not the native Windows build.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel DCAI Platform & System Engineering



--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals