This is apparently part of the wide-oriented stream support? Extending the conversion from wchar encoding to bytes ?
In addition to the above characters,
fopen() and freopen() support the following syntax in mode: ,ccs=string The given string is taken as the name of a coded character set and the stream is marked as wide-oriented. Thereafter, internal conversion functions convert I/O to and from the character set string. If the ,ccs=string syntax is not specified, then the wide-orientation of the stream is determined by the first file operation. If that operation is a wide-character operation, the stream is marked wide-oriented, and functions to convert to the coded character set are loaded.

On Sun, Mar 21, 2021 at 12:47 PM Thiago Macieira via SG16 <sg16@lists.isocpp.org> wrote:
On Sunday, 21 March 2021 06:40:44 PDT Victor Zverovich wrote:
> > Strictly speaking, that's implementation-defined. You can reopen stdout
> > with the ",css=<codec>" flag to fopen to cause transcoding to happen.
>
> Interesting, would it be standard-compliant? In any case, MSVC doesn't do it
> according to the test.

Yes, it's standards-compliant to transcode. The ",ccs" argument is not in the
C standard (see https://cigix.me/c17#7.21.5.3) nor POSIX[1] but informing how
you want the C library to transcode does not prevent it from choosing to do so
on its own. The existence of wprintf() is sufficient reason for that ability
to exist.

MS documentation[2] is that the ",ccs" argument can be used to specify one of
the Unicode encodings, but not the ACP (I guess that's just the default). The
glibc documentation says that any encoding understood by iconv is valid there.

[1] https://pubs.opengroup.org/onlinepubs/9699919799/functions/fopen.html
[2] https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/fopen-wfopen

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DPG Cloud Engineering



--
SG16 mailing list
SG16@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/sg16