Date: Sun, 01 Sep 2024 09:44:04 -0700
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.
> 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
Received on 2024-09-01 16:44:07