On Thursday 20 March 2025 21:57:42 Martin Storsjö wrote: > On Thu, 20 Mar 2025, Pali Rohár wrote: > > > For example in -std=c99 mode we should rather follow C99 standard and > > hence %s in wprintf should take char*. > > So far, we have decided to match MSVC in this aspect. > > For MSVC 2015 CTP1 they first announced that they would change MSVC to > default to the C99 compatible mode, but after overwhelming response from > their users, they reverted this decision, so it defaults to the old legacy > mode. > > Yes, I'm aware that this is inconsistent with when __USE_MINGW_ANSI_STDIO=1 > is defined (as it is done for msvcrt.dll when building with -stdc=c99, but > not for UCRT), as that uses the C99 compatible mode. > > But I have not heard any reports about this inconsistency - which can mean > one out of: > - the status quo is correct > - very few codebases use wchar_t > - msys2 hardcodes __USE_MINGW_ANSI_STDIO=1 when building most of their > packages anyway, so much fewer are exposed to this default case > > Overall, very few portable codebases use wchar_t anywhere else other than > for windows specific codepaths. Therefore, I think it makes more sense to > match MSVC, than to try to match the C99 standard in this aspect, if nobody > else is using wchar_t in the C99 standard way. > > But anyway, this whole discussion is mostly beside the point here. We have a > current default behaviour - this patchset is not changing that. Whether we > should change that default is a different discussion.
Ok, so move forward. If this is not changing the behavior, we can discuss later as you wrote. > > But __ms_wprintf should take wchar_t* (independently of -std= option) as > > this is on what tchar.h depends. > > I really think that is overkill and not necessary. If calling __ms_wprintf, > I would expect to get the same as if I would be calling wprintf() with > __USE_MINGW_ANSI_STDIO=0 - whichever default or customized behaviour that > is. I thought that the intent is opposite. __ms_wprintf() would always provide MS behavior (independently of -std= option) and wprintf() would provide the behavior according to -std= option. Maybe this is something which should be clarified and documented? Anyway, as your patches are not changing behavior, this is not a blocker. > > My original idea was to define everything in separate .c files, not via > > aliases in header files. > > This could also solve above problem and for example problems with > > non-standard _vsnprintf or _vsnwprintf functions (which should never use > > _CRT_INTERNAL_PRINTF_STANDARD_SNPRINTF_BEHAVIOR and always use > > _CRT_INTERNAL_PRINTF_LEGACY_VSPRINTF_NULL_TERMINATION). > > Those extra flags for the specific functions that want specific behaviours > regarding null termination and other details is not a problem; we already > add those extra flags as necessary in the right functions - I don't see what > problem there is to solve about that? The point is that the _CRT_INTERNAL_PRINTF_STANDARD_SNPRINTF_BEHAVIOR needs to be cleared and _CRT_INTERNAL_PRINTF_LEGACY_VSPRINTF_NULL_TERMINATION added. That is because underscored _vsnprintf is not standard snprintf. But it should be easy. I'm just writing to not forget about it. > > But you said that this is not maintainable and I have not come up with a > > better idea. > > Yes, your suggestion would create duplicate copies of all these stdio > functions, for all the __ms_ function names. We don't want that. > > It feels like you're suggesting extra complexity just to fulfill the corner > case correctness that only you are requesting, that nobody else wants. That was just my idea. I'm not against your idea, just I'm saying that I do not know if it is better or not. > > One suggestion: > > What about moving all ucrt stdio functions into own subdirectory? > > E.g. mingw-w64-crt/stdio/ucrt/ So we do not need to prefix every file > > with ucrt_. It would be quite confusing how we should call a file which > > contains UCRT's _vsnprintf function and file with UCRT vsnprintf function. > > I don't mind creating a subdirectory for the UCRT files - but I don't see > how that changes anything. Even with a separate subdirectory, I don't want > another 30+ extra copies of all the stdio functions. Nobody else wants that. This was just unrelated idea. Just when I look at that we have more files prefixed with ucrt_, I though that it would be better to move it into separate directory. It is just a cosmetic change/idea. > > FWIW, if we don't have a good path forward about this, we should revert > 581532b8e49a0e10cbdfe2332a8c1d61ff3d6820 and stop referencing symbols that > don't exist. > > // Martin I'm fine with it. _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
