On Thu, 20 Mar 2025, Pali Rohár wrote:
On Thursday 20 March 2025 23:00:54 Martin Storsjö wrote:
And with that in mind, I'm actually wondering if we should revert
581532b8e49a0e10cbdfe2332a8c1d61ff3d6820 regardless of this patchset? I'm
actually less convinced that we want to have this distinction. If we have
printf() and wprintf() with __USE_MINGW_ANSI_STDIO=1 semantics, then it can
also be seen quite confusing if _tprintf() behaves differently.
// Martin
When __USE_MINGW_ANSI_STDIO=1 is enabled then we already have other
differences for other underscored printf and scanf functions.
For example _scprintf() or _snprintf() which are not affected by the
__USE_MINGW_ANSI_STDIO settings.
Sure, that is true...
And I think that similar scenario is with _stprintf() macro.
Most common usage of _stprintf() macro is of form:
_stprintf(buffer, _T("%s"), _T("string"));
So I think that whatever mingw-w64 will do, the above call should work
independently of __USE_MINGW_ANSI_STDIO setting.
Sure - my patches does keep that working as is.
If the user overrides the UCRT stdio options to set the C99 wide char mode
as default, it would break, but it would break in the exact same way as it
would do with MSVC too, if you'd override the wide char mode there.
And reverting 581532b8e49a ("headers: Fix _*tscanf and _*tprintf macros
which expands to ISO C functions") will break above usage.
Ok, fair enough.
// Martin
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
