Subject: Re: Questions for LEWG for P2093R4: Formatted output
From: Steve Downey (sdowney_at_[hidden])
Date: 2021-03-22 10:09:31
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*:
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 <
> 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
> C standard (see https://cigix.me/c17#220.127.116.11) nor POSIX but informing
> 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
> to exist.
> MS documentation is that the ",ccs" argument can be used to specify one
> the Unicode encodings, but not the ACP (I guess that's just the default).
> glibc documentation says that any encoding understood by iconv is valid
>  https://pubs.opengroup.org/onlinepubs/9699919799/functions/fopen.html
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel DPG Cloud Engineering
> SG16 mailing list
SG16 list run by email@example.com