This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Open status.
Section: 184.108.40.206 [filebuf.members] Status: Open Submitter: Tim Song Opened: 2017-03-09 Last modified: 2018-01-22
View all other issues in [filebuf.members].
View all issues with Open status.
LWG 2676 specified basic_filebuf::open(const std::filesystem::path::value_type* s, ios_base::openmode mode) by simply reusing the specification for the const char* overload, but that specification is incorrect for the wide overload: it says that s is an NTBS — a null-terminated byte string — which it isn't. Moreover, it specifies that the file is opened as if by calling fopen(s, modstr), but that call is ill-formed if s isn't a const char*.
[2017-07 Toronto Wed Issue Prioritization]
[2017-11 Albuquerque Wednesday issue processing]
Status to Open; Jonathan to provide wording.
[2018-01-16; Jonathan and Tim Song provide wording]
We'll have to ask the Microsoft guys if "as by a call to fopen" is OK for them. There are paths that can be represented as a wide character string that can't reliably be converted to narrow characters (because they become dependent on the current codepage, or some other Windows nonsense) so they definitely won't use fopen. But as long as they call something that behaves like it (which should allow _fwopen), I think they'll still meet the spirit of the wording.
This wording is relative to N4713.
Edit 220.127.116.11 [filebuf.members] as indicated:
basic_filebuf* open(const char* s, ios_base::openmode mode); basic_filebuf* open(const filesystem::path::value_type* s, ios_base::openmode mode); // wide systems only; see 30.9.1 [fstream.syn]
-2- Effects: If is_open() != false, returns a null pointer. Otherwise, initializes the filebuf as required. It then opens
a file, if possible, whose name is the ntbs s (as if by calling fopen(s, modstr)). The ntbs modstr isdetermined from mode & ~ios_base::ate as indicated in Table 117. If mode is not some combination of flags shown in the table then the open fails. -3- If the open operation succeeds and (mode & ios_base::ate) != 0, positions the file to the end (as if by calling fseek(file, 0, SEEK_END)).(footnote 330) -4- If the repositioning operation fails, calls close() and returns a null pointer to indicate failure. -5- Returns: this if successful, a null pointer otherwise.