#2018 swprintf and vswprintf have incorrect declaration signature.

[Earnie Boyd]

The swprintf and vswprintf functions should contain a size_t count parameter as the 2nd argument. Based on the comment in the header these must have been incorrect on MSDN once upon a time but MSDN contains the correct signature for the functions.

[Earnie Boyd]

Well MSDN may say this but the attached test proves otherwise. The test was taken from the IBM information center for a test of the function.

Works

gcc -o swprintf_test.exe swprintf_tests.c -g /c/windows/system32/msvcrt.dll -DMSVCRT_VERSION=700

Doesn't work

gcc -o swprintf_test.exe swprintf_tests.c -g /c/windows/system32/msvcrt.dll -DMSVCRT_VERSION=800

It doesn't matter if you change the runtime version either, I also used /c/windows/system32/msvcr100.dll with the same bad results.

GDB reports that the error is a SIGSEGV from strncmp() function.

[Earnie Boyd]

What about this patch adapted from [#1807]?

[Earnie Boyd]

Except that we cannot inline because of the variable argument list. We could add this to libmingwex.a as __mingw_swprintf instead perhaps?

[Earnie Boyd]

I implemented these as is in mingwex with a NO_MINGWEX guard for the declaration to bring back the broken MSness.

[Keith Marshall]

Earnie,

I'm reopening this, because I'm not satisfied that your "fix" is adequate. I can see what you've done, and how it might be considered as providing a solution, but it certainly isn't robust! It is all too easy to get your default ISO-C conforming function prototypes paired with the broken Microsoft implementations in MSVCRT.DLL, resulting in the application crashes which your test case so admirably demonstrates.

On the ticket itself, you actually do allude to the appropriate solution, which is to provide __mingw_swprintf() and __mingw_vswprintf() implementations in libmingwex.a, and redirect the function calls to them, (as we already do for the char * implementations of the printf() family), but what you've committed doesn't do this. We need to revisit this, and implement it consistently with the printf() replacements.

[Keith Marshall]

On further reflection, I now believe that we need neither __mingw_swprintf() nor __mingw_vswprintf(). However, we definitely must not provide your external implementations of swprintf() and vswprintf() in libmingwex.a; doing so unconditionally breaks your promise to serve up the old (broken) Microsoft API, when the user defines _NO_MINGWEX_ -- yet another of your prolific inventions, which should really be _CRT_NON_CONFORMING_SWPRINTFS, to maintain consistency with MSDN documentation.

To illustrate what I think is a more appropriate solution, I've reworked your "fix" w.r.t. stdio.h; the attached patch shows my reworking, based on the state of 4.1-dev tip as of your committed "solution". This reworking offers the following advantages:--

1. It uses _CRT_NON_CONFORMING_SWPRINTFS, as documented on MSDN, instead of your hitherto unheard of _NO_MINGWEX_, to select the old Microsoft API.

2. It ensures that an appropriate API is always declared, correcting the defect in your implementation, whereby no API at all is declared, if both __STRICT_ANSI__ and _NO_MINGWEX_ are defined; with my implementation, __STRICT_ANSI__ overrides _CRT_NON_CONFORMING_SWPRINTFS, ensuring that the ISO-C conforming API is exposed in all cases, except when __STRICT_ANSI__ is not defined, and _CRT_NON_CONFORMING_SWPRINTFS is defined.

3. It does not rely on swprintf() and vswprintf() being provided in libmingwex.a; indeed, these must be removed, to allow the linker to access the MSVCRT.DLL versions, when _CRT_NON_CONFORMING_SWPRINTFS is defined.

Do note that, as it stands, this reworked implementation is incomplete. In addition to the mandatory removal of swprintf() and vswprintf() from libmingwex.a, the API must also be declared identically in wchar.h; this would be best accomplished by moving the API declaration to a standalone header, (such as Linux would do in the /usr/include/bits directory -- perhaps we might consider /mingw/include/bits/swprintf.h or similar), then including this in both stdio.h and wchar.h.