In this particular case it is quite unfortunate that (afaik) Windows is the only platform which cares about binary vs. non-binary I/O modes, but at the same time it does not implement standard way of doing this.
While it is good to be more conformant to ISO C, I believe it is better try to avoid situations when compiling the same code under MSVC and mingw-w64 will result in different behavior (unless it fixes an actual bug). I'm not sure about this either, I think I'd prefer keeping compatibility with MSVC if possible. - Kirill Makurin ________________________________ From: Martin Storsjö <[email protected]> Sent: Tuesday, October 21, 2025 4:50 AM To: Pali Rohár <[email protected]> Cc: [email protected] <[email protected]>; LIU Hao <[email protected]>; Kirill Makurin <[email protected]> Subject: Re: [PATCH 5/5] crt: Add support to call freopen() with NULL path On Mon, 20 Oct 2025, Pali Rohár wrote: > I understand your concerns. This code is also using lower level WinAPI > calls and constants and also direct ntdll.dll syscalls which is also not > so well documented and in most cases marked as "can be changed". Oh, I missed that bit (I didn't read the patch that far). Even more reason to stay away from doing it... > More times, I hit the problem that I cannot simply read binary file from > stdin and freopen "fix" did not work. So we are in situation that > applications do not use freopen stdin because it does not work with > existing toolchains. Indeed; the canonical way of doing this so far is using _setmode. It's of course a little harder to discover, when the supposedly standard function for doing it doesn't work. > And providing the fix into toolchain is harder as > it needs to touch internals of CRT and low level ntdll.dll calls which > of course makes sense to not take it as it has a questionable usage. > > > One idea: The primary motivation of this change is ability to switch > binary/text mode. What about reducing the freopen-NULL ability to just > change the 'b', 't' and ',ccs=' flags with completely ignoring all > others? This can be done by the _setmode() function (fifth step only) > and do not need to touch any internals. That would be much more acceptables, yes. > It is something which is useful? Or it is worse to have such > reduced/incomplete implementation and it is really better to rather do > not change the existing freopen support provided by mingw-w64? That is a good question - I'm not sure. In one sense, it would make the common case of switching stdin/stdout to binary mode much more discoverable, using standard C99 functions. But on the other hand, it also fragments the Windows development landscape - users code end up silently depending on this, while the same code does compile fine on MSVC, but just not working in the same way. I'm not sure if it is better to have such a half-support for the feature or not. Especially as there is no existing code out there that does this... What do the other regulars think about this? // Martin _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
