C99 requires that freopen() can be called with NULL path and then it
just modify the mode of FILE* stream. But msvcrt's freopen() crashes if
the path is NULL.
So C99 is prepared to change text mode of stdin to binary mode
(specially for Windows and DOS systems), but Windows msvcrt.dll does not
implement it. Maybe mingw-w64 could provide C99 complaint wrapper around
msvcrt's freopen() to allow change mode via _setmode?
Also it would be good to check if UCRT supports C99 NULL path in
freopen() or not. I did this test only for msvcrt.dll and in past.
Changing UNICODE translation via _setmode in POSIX applications is
really very unlikely.
On Wednesday 10 September 2025 10:44:19 Kirill Makurin wrote:
> I guess I confused glibc with some other implementation I was testing long
> time ago...
>
> You're right, we can't just `freopen ("/dev/stdin", ..., stdin)` with binary
> mode on Windows, I didn't think of it. However, I still find it unlikely that
> they will ever use _setmode to enable Unicode translation mode.
>
> Now that I think of it, _setmode may not be the best way to implement fwide.
>
> My thoughts about implementing fwide with _setmode were that if you're using
> wide I/O functions there must be a reason for it, such as need to handle
> characters which may not be supported by single-byte or double-byte code
> pages. Using Unicode translation mode would ensure that they are written and
> read back properly.
> ________________________________
> From: Pali Rohár <pali.ro...@gmail.com>
> Sent: Wednesday, September 10, 2025 2:55 AM
> To: Kirill Makurin <maiddais...@outlook.com>
> Cc: mingw-w64-public <mingw-w64-public@lists.sourceforge.net>
> Subject: Re: _getmode
>
> Ou... This character-orientation feature is something I know that exist
> but I totally forgot about it.
>
> On Tuesday 09 September 2025 11:38:54 Kirill Makurin wrote:
> > One more thing about _setmode. You may know that CRT's fwide[1] is just a
> > stub and it is even documented to do nothing. If there would be a reliable
> > and consistent way to obtain translation mode, it would be possible to
> > implement working replacement for it.
>
> Hm... That is an interesting idea. But I doubt that there is some better
> way how to get current mode than accessing the CRT internals.
>
> Anyway, I'm not sure if the _setmode is a good for implementing fwide.
> Normally fwprintf uses the encoding from setlocale to convert wide
> buffer to byte buffer (before writing data to file).
>
> But _setmode when operating in wide-mode allows to choose just UTF-8 or
> UTF-16 encoding for converting wide buffer to byte buffer, completely
> ignoring the encoding set by setlocale.
>
> So for me, this _setmode looks like an another feature independent of
> fwide and not compatible for it.
>
> > _setmode is CRT stuff, so I think it is safe enough to assume that POSIX
> > applications will not call it. ISO C way to achieve similar thing is fwide.
> > In theory, implementation could track which FILEs were put to "wide" mode
> > and implementation of printf/scanf could make use of this information.
>
> _setmode is the only way how to change stdin or stdout to binary mode.
> So POSIX application which works in a way argv[1] is input file and when
> is not specified then stdin is used, in more cases contains #ifdef for
> windows to change stdin / stdout to binary mode via _setmode to make
> this working.
>
> > Also, if I remember correctly, ISO C says that once stream mode was set
> > with either fwide or explicit I/O operation it cannot be changed and
> > corresponding (narrow or wide) versions of stdio functions must be used to
> > perform I/O on that stream.
>
> Yes, it is supposed to work in this way.
>
> > In practice, it seems that some implementation (CRT and glibc for example)
> > are ok with mixing them.
>
> glibc does not allow to mix printf and wprintf. I have tried it now.
> But I'm not sure if it allows to call fwide to change existing mode if
> is already set.
>
> > [1] https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/fwide
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
