On Monday 20 October 2025 14:37:44 Martin Storsjö wrote: > On Sun, 21 Sep 2025, Pali Rohár wrote: > > > C99 allows to pass NULL path into freopen() function which just changes the > > mode of FILE*. Both msvcrt and UCRT returns error when NULL path is passed. > > > > The primary use case of this C99 feature is to change stdin / stdout mode > > from text to binary and so allow processing of binary data on stdin or > > stdout. > > > > Implement support for NULL path by renaming existing freopen symbol to > > _freopen and then providing mingw-w64 wrapper function freopen() which will > > either call renamed _freopen() or just changes the mode on existing FILE* > > stream. > > > > Because FILE struct has different offsets to members between msvcrt and > > UCRT builds, it is needed to have separate compilation unit for msvcrt and > > UCRT builds. > > --- > > Overall, I'm a little sceptical to this patch. > > First off - this patchset adds a lot of things to public headers that aren't > supposed to be in public headers. > > If we feel that we do want to make such assumptions about UCRT internals, > then we should keep those private defines in mingw-w64-crt internal headers, > not expose those defines to everybody else. But I'm not sure if this usecase > warrants hardcoding assumptions about UCRT internals. > > I'm also a little sceptical about the use case overall. > > Yes, C99 says you should be able to do this. But currently, on Unix, nobody > needs to care about binary vs non-binary stdio modes. On Windows, no > existing code works with freopen this way, as neither mingw nor MSVC support > this. So there is no preexisting code that would need this. All code that > targets Windows that wants to do this already does it differently already. > So by implementing this, we gain a little standards compliance, but we also > divide the ecosystem (any code written with mingw-w64 assuming this > behaviour won't work on official SDKs). > > Therefore, plus the fact that it requires poking into UCRT internals, makes > me less inclined to accept this change. > > If it would be a C standard function which is commonly used in a portable > fashion on other platforms already, I would be more inclined to support it > in mingw, even though MSVC might not support it. > > Also in this case, it could be good to file a bug report to MS about this > deviation from the C99 standard. > > // Martin
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". 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. 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. 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? _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
