[Bug libstdc++/103655] New: "x" does not exist on windows and dos

[Bug libstdc++/103655] New: "x" does not exist on windows and dos

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103655

            Bug ID: 103655
           Summary: "x" does not exist on windows and dos
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: unlvsur at live dot com
  Target Milestone: ---

In today's patch.

https://github.com/gcc-mirror/gcc/commit/a219139e986a4200a9105d7c1fa63735d2945994

std::ios::noreplace uses "x". However, that is not correctly supported by
msvcrt and dos djgpp.

The correct way is to directly use CreateFileW (on windows NT) or NtCreateFile
and CreateFileA on windows 9x. Then call _open_osfhandle to create an fd then
call _wfdopen(on windows NT) or _fdopen(on windows 9x) on Windows

Create an NT handle with NtCreateFile (You also need RtlNtStatusToDosError and
RtlDosPathNameToNtPathName_U_WithStatus or RtlDosPathNameToNtPathName_U).

https://github.com/tearosccebe/fast_io/blob/6081ae18b34820c3c69b81628f520f5fafcfb815/include/fast_io_hosted/platforms/nt.h#L67

Or create a win32 handle with CreateFileA (on Windows 9x) and CreateFileW (on
Windows NT)

https://github.com/tearosccebe/fast_io/blob/6081ae18b34820c3c69b81628f520f5fafcfb815/include/fast_io_hosted/platforms/win32.h#L201

Use win32 or nt handle to call _open_osfhandle to create a POSIX fd.

https://github.com/tearosccebe/fast_io/blob/6081ae18b34820c3c69b81628f520f5fafcfb815/include/fast_io_hosted/platforms/posix.h#L58

https://github.com/tearosccebe/fast_io/blob/6081ae18b34820c3c69b81628f520f5fafcfb815/include/fast_io_hosted/platforms/posix.h#L961

Then use _wfdopen on Windows NT and _fdopen on Windows 9x to open a FILE*

https://github.com/tearosccebe/fast_io/blob/6081ae18b34820c3c69b81628f520f5fafcfb815/include/fast_io_legacy_impl/c/impl.h#L29

Then construct a std::filebuf with FILE*

https://github.com/tearosccebe/fast_io/blob/6081ae18b34820c3c69b81628f520f5fafcfb815/include/fast_io_legacy_impl/filebuf/filebuf_file.h#L60


On DOS. You need __dos_creat,__dos_creatnew,__dos_open
https://github.com/tearosccebe/fast_io/blob/6081ae18b34820c3c69b81628f520f5fafcfb815/include/fast_io_hosted/platforms/posix.h#L1063


So libstdc++ using fdopen to open FILE* with fd is incorrect. On windows NT
kernel, we MUST use _wfdopen since _fdopen involves locale, which is not
thread-safe.

[Bug libstdc++/103655] "x" does not exist on windows and dos

[de34 at live dot cn]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103655

--- Comment #1 from Jiang An <de34 at live dot cn> ---
It seems that MS implemented the "x" mode in 2020:

https://github.com/MicrosoftDocs/cpp-docs/commit/3e0701d935614423e1f09a6712cb5b5e28c43022#diff-be5df6fa41d451f0736c5cd8d863fb3bccfd2b49fbd6b0f7f5de6c07c87700ac

So the alternative methods should be restricted to old OSes.

[Bug libstdc++/103655] "x" does not exist on windows and dos

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103655

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
"We implemented this C11 feature a while ago and backported it to all OSes"

That suggests it should become available everywhere, no?

[Bug libstdc++/103655] "x" does not exist on windows and dos

[de34 at live dot cn]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103655

Jiang An <de34 at live dot cn> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |de34 at live dot cn

--- Comment #3 from Jiang An <de34 at live dot cn> ---
I'm not sure whether the change is backported to NT5 OSes as the support for
them has ended for a long time. Perhaps libstdc++ still need to be used on
Windows XP?

[Bug libstdc++/103655] "x" does not exist on windows and dos

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103655

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2022-01-20
             Status|UNCONFIRMED                 |SUSPENDED

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I'm not interested in supporting a dead proprietary OS that even the vendor no
longer supports. Libstdc++ will still work on XP for the most part. If a brand
new C++23 feature doesn't work on an ancient OS, that's tough luck. I'm not
going to do extra work to enable it.

Suspending on the basis that this should be fixed by updates to the MSVC CRT.

[Bug libstdc++/103655] "x" does not exist on windows and dos

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103655

--- Comment #5 from cqwrteur <unlvsur at live dot com> ---
(In reply to Jonathan Wakely from comment #4)
> I'm not interested in supporting a dead proprietary OS that even the vendor
> no longer supports. Libstdc++ will still work on XP for the most part. If a
> brand new C++23 feature doesn't work on an ancient OS, that's tough luck.
> I'm not going to do extra work to enable it.
> 
> Suspending on the basis that this should be fixed by updates to the MSVC CRT.

windows has both msvcrt and ucrt. I do not think msvcrt correctly supports "x"

[Bug libstdc++/103655] "x" does not exist on windows and dos

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103655

--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Does it silently ignore the x and open in non-exclusive mode, or does it give
an error?

Giving an error is fine, it just means noreplace can't be used on those
systems.

Silently ignoring the x and opening in non-exclusive mode is not OK, that would
lead programs to think they had exclusive access when they didn't.