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_at_[hidden]> on behalf of Thiago Macieira via Std-Proposals <std-proposals_at_[hidden]>
Sent: Sunday, September 1, 2024 6:44:13 PM
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>; Jeremy Rifkin <rifkin.jer_at_[hidden]>
Cc: Thiago Macieira <thiago_at_[hidden]>
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_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals