Ensure that all these MS specific _*t* macros always expands to MS variant
of scanf and printf functions independently of __USE_MINGW_ANSI_STDIO.
Majority of the _*t* macros expands to MS specific variants of stdio
functions which are not provided by mingw when __USE_MINGW_ANSI_STDIO=1.
But some few are, e.g. _tscanf which currently expands to scanf or wscanf.
And this can cause that _tscanf behaves differently than _tscanf_l (which
does not have __USE_MINGW_ANSI_STDIO=1 replacement.
Another example is %s in _stprintf() macro. MS variant of wide-printf
treats %s as wchar_*t, but C95+ mandates that %s is always char*.
_stprintf() is suppose to be called as:
_stprintf(buffer, _T("%s"), _T("string"));
And wide variant would work correctly only in the case %s takes wchar_t*.
With this change behavior of all _*t* macros would be same and expands
always only to MS function, which also ensures compatibility of %s with
arguments passed to _*t* macros.
Signed-off-by: Martin Storsjö <martin@martin.st>
Per MS documentation, macros _stprintf and _vstprintf always expands to
s(w)printf function variant which does not take buffer size argument.
https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/sprintf-sprintf-l-swprintf-swprintf-l-swprintf-l
So _stprintf() expands either to C89 sprintf() function or to MS-specific
_swprintf() function. C95 swprintf() takes buffer size argument and so, it
is not compatible for _stprintf() and cannot be used.
So replace swprintf by _swprintf in _UNICODE mode of _stprintf expansion.
Signed-off-by: Martin Storsjö <martin@martin.st>
ISO C does not define (v)snwprintf() function. But ISO C11 in optional
Appendix K defines (v)snwprintf_s() function which has same behavior as
non-wide ISO C11 Appendix K (v)snprintf_s() function (which is secure
variant of (v)snprintf()).
Function (v)snwprintf() is not provided by any MS CRT library and neither
by any MS header file.
mingw32 runtime and mingw-w64 runtime since beginning provide function
named (v)snwprintf (without leading underscore) and define it under symbol
name __mingw_(v)snwprintf. This function differs from ISO C (v)swprintf()
just in return value. ISO C (v)swprintf() when buffer is too small returns
negative value but this (v)snwprintf() returns size of buffer in wide
characters, similarly to non-wide ISO C (v)snprintf() function, and also
similarly to ISO C11 Annex K (v)snwprintf_s(). This non-ISO (v)snwprintf()
and both ISO C (v)snwprintf_s() and (v)snprintf() always fill trailing nul
character.
But when __USE_MINGW_ANSI_STDIO=0 the (v)snwprintf() is redirected to
__ms_(v)snwprintf() function, which is just wrapper around msvcrt
_vsnwprintf() function. And msvcrt _vsnwprintf() function does not fill
trailing nul character and does not return required buffer size when output
buffer is too small.
So fix __ms_(v)snwprintf() functions to properly fill trailing nul
character and return required size of bufer, like ISO C vsnprintf().
Also adjust header files and remove wrong symbol aliases for (v)snwprintf
symbols from def files.
This will make API of (v)snwprintf() function compatible for both
__USE_MINGW_ANSI_STDIO=0 and __USE_MINGW_ANSI_STDIO=1 modes and also to
mimics API of ISO C (v)snwprintf_s() function.
Signed-off-by: Martin Storsjö <martin@martin.st>
C95 compatible (v)swprintf function takes size argument and returns
negative value on error. __mingw_(v)swprintf function (which is called
when __USE_MINGW_ANSI_STDIO=1) does not take size argument at all.
Fix this problem by adjusting mingw_sprintfw.c and mingw_vsprintfw.c
files to include "n" function variant and also adjust mingw_vsnprintf.c
implementation to return correct value on error for ISO C95+ variant.
Fix also header files to provide correct declarations for
__mingw_(v)swprintf() function and then also inline definitions for
(v)swprintf() when __USE_MINGW_ANSI_STDIO=1.
Note that mingw-w64 provides also additional non-ISO C (v)snwprintf()
function which is built from the same mingw_vsnprintf.c source file.
Distinguish between non-ISO C (v)snwprintf() and ISO C95+ (v)swprintf() by
a new __BUILD_WIDEAPI_ISO macro.
With all these changes, functions swprintf() and vswprintf() when
__USE_MINGW_ANSI_STDIO is set to 1 are now compatible with ISO C95+.
Signed-off-by: Martin Storsjö <martin@martin.st>
msvcr80+ has following wide-buffer swprintf like function symbols, none of
them is compatible with C95 (v)swprintf function, differences are:
_(v)swprintf - does not take buffer size argument, like non-wide C89
sprintf
_(v)snwprintf - does not fill nul-term wide char if there is not space
for it, like non-wide msvcr _(v)snprintf
_(v)swprintf_c - clears the first wide character in buffer on error
(error means that there is no space for nul-term or
conversion error occurred)
Version before msvcr80 has following function symbols:
_(v)snwprintf - same as in msvcrt80+
(v)swprintf - same as _(v)swprintf in msvcrt80+
There is no (v)swprintf symbol in msvcr80+ (neither in UCRT) and there are
no _(v)swprintf_c/_(v)swprintf symbols before msvcr80.
Additionally msvcr80+ header files defines (v)swprintf() function as inline
wrapper function around _vswprintf_c_l() with NULL locale, which is same as
_vswprintf_c(). Therefore that msvcr80+ inline function (v)swprintf() is
not C95 compatible.
UCRT header files provides all those msvcr80+ swprintf family functions
defined as inline. But UCRT changed behavior of _(v)swprintf_c function,
on error it does not clear the first wide character in buffer, but instead
puts the nul wide character at current position. So with this change the
(v)swprintf() function definition in UCRT header file is C95 compatible.
mingw-w64 header files declares and defines (v)swprintf() without the
buffer size argument, matching the pre-msvcr80 (v)swprintf symbol. So
mingw-w64 has currently broken C95+ support for swprintf(), vswprintf(),
__ms_swprintf() and __ms_vswprintf() symbols, and for swprintf() and
vswprintf() functions provided by mingw-w64 header files when macro
__USE_MINGW_ANSI_STDIO is set to 0 (which is default for UCRT).
Fix this issue.
Ensure that swprintf and vswprintf symbols are always C95 compatible in
every CRT import library. Function symbols which do not take buffer size
are always under name with underscore prefix.
For non-UCRT import libraries provide mingw-w64 swprintf and vswprintf
implementations which calls _vsnwprintf and fill nul-term wide char. Original
pre-msvcr80 DLL symbols swprintf and vswprintf are renamed to _swprintf and
_vswprintf, for compatibility with msvcr80+ and UCRT.
Fix declarations of __ms_swprintf and __ms_vswprintf functions in header
files to include buffer size argument, to make them C95 compatible too.
crt-aliases.def.in file is updated to reflect this change (which completely
drops incompatible __ms_swprintf and __ms_vswprintf aliases and then also
unused PRE_C95_SWPRINTF macro).
With all these changes, functions swprintf() and vswprintf() when
__USE_MINGW_ANSI_STDIO is set to 0 are now compatible with ISO C95+.
Signed-off-by: Martin Storsjö <martin@martin.st>
Macro _tcstok takes two arguments, so in _UNICODE mode it has to expand to
two-argument _wcstok() function, instead of to three-argument wcstok()
function.
Also in C mode (as opposite of C++ mode), function wcstok() cannot be
called with just two arguments, so fix _wcstok_l macro to call _wcstok()
function.
Signed-off-by: Martin Storsjö <martin@martin.st>
All non-UCRT crt library versions provide wcstok symbol which is not C95+
compatible. Its function prototype is missing the third argument. In UCRT
version this function without third argument is named _wcstok(). So rename
wcstok symbol to _wcstok in all non-UCRT import libraries for compatibility
with UCRT.
msvcr80+ provides wcstok_s symbol which is C95+ compatible wcstok()
function. msvcr80+ wcstok_s() function has same function prototype as C95+
wcstok() and the only difference between MS wcstok_s and C95 wcstok is that
MS wcstok_s validates parameters and sets errno. C95 version has undefined
behavior when called with invalid parameters (e.g. Linux version crashes).
So add appropriate aliases of wcstok_s in msvcr80+ import libraries to have
C95+ compatible wcstok() function under the correct C95 name wcstok.
For pre-msvcr80 import libraries, provide mingw-w64 implementation of
wcstok_s() and C95+ wcstok() functions. So when linking with any crt
library, the wcstok symbol resolve to the correct C95 compatible wcstok()
function. mingw-w64 implementation of wcstok is copied from musl libc which
is very compact and some parts from musl libc are already used in mingw-w64.
Update header files to reflect these changes. With this change, C95+
compatible wcstok() function is available for all builds, not only UCRT as
it was before this change.
For compatibility with C99, add missing restrict keyword for last wcstok()
argument in header files.
mingw-w64 is currently missing MS _wcstok() function for UCRT builds.
So provide it into UCRT import libraries.
Visual Studio 2015+ redefines wcstok() to _wcstok() when macro
_CRT_NON_CONFORMING_WCSTOK is defined. And in C++ mode it provides
overloaded C++ function wcstok() with two arguments unless the macro
_CRT_NO_INLINE_DEPRECATED_WCSTOK is defined. It is documented on:
https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/strtok-strtok-l-wcstok-wcstok-l-mbstok-mbstok-l
Implement same logic for _CRT_NON_CONFORMING_WCSTOK to get the old behavior
by default. And provides C++ inline two-argument function unless define
_CRT_NO_INLINE_DEPRECATED_WCSTOK is set.
With this change mingw-w64 always provides C95+ compatible wcstok()
function and MS two-arg _wcstok() function in all CRT import libraries.
Also every CRT import library provides MS wcstok_s() function.
Signed-off-by: Martin Storsjö <martin@martin.st>
Previously they cast their first enum operands to `int&` and operate on
integers, which is type-punning and maybe not safe. This commit makes them
call the corresponding non-assignment operators instead. As they modify their
arguments, they are only `constexpr` since C++14.
Also regroup them a little.
Signed-off-by: LIU Hao <lh_mouse@126.com>
First, these intrins read from and write to thread-local memory. The TEB
contains a pointer to itself in the DS segment, known as the `Self` field of
`struct _NT_TIB`, which means the TEB is semantically in the same address
space as other objects, so these asm statements must clobber "memory". If an
asm statement writes to memory that is not passed with "m" constraints, then
the compiler shall be noted that it has unknown side effects, by adding a
`volatile` qualifier.
Second, for Intel syntax, this commit removes superfluous prefixes in front of
segment register names.
Third, previously `Offset` was cast to a pointer and dereferenced, and then
passed to inline assembly as a memory operand using the `m` constraint. This
was a pure hack. GCC assumes that a memory operand should belong in the DS
segment, so it appeared to reference unknown memory, and caused warnings like
intrin-impl.h:849:1: warning: array subscript 0 is outside array bounds of
'long long unsigned int[0]' [-Warray-bounds=]
849 | __buildreadseg(__readgsqword, unsigned __int64, "gs", "q")
| ^~~~~~~~~~~~~~
This commit passes the address by register instead. For Intel syntax, there is
no way to print the `DWORD PTR` thing, so unfortunately the value also has to
be passed by register. It's suboptimal, but should be safe.
For x86-64, the use of a 32-bit address requires an address size override
prefix. However, it's deliberate, as zero-extending a 32-bit register (like
`mov edi, edi`) would require two additional bytes.
Signed-off-by: LIU Hao <lh_mouse@126.com>
Fix ULongToChar to return -1 on overflow, like it does in the SDK.
Fix LongLongToUIntPtr and LongLongToULongPtr so they work on 32-bit.
Remove about 150 macros added this year that just redefine an existing function.
Signed-off-by: Jacek Caban <jacek@codeweavers.com>
45629c13ef added this macro in tbs.h, causing
a warning about redefinition:
mingw-w64-headers/include/tbs.h:63: warning: "TBS_SUCCESS" redefined
63 | #define TBS_SUCCESS 0
No Windows SDK has this macro in winerror.h, so this macro in winerror.h
should be removed, and the one in tbs.h is preferred.
Signed-off-by: LIU Hao <lh_mouse@126.com>
The _l suffixed wchar ctype functions, such as _iswalpha_l,
are available in msvcrt.dll, but only since Vista. They're also
available in the properly versioned msvcrt versions since
msvcr80.dll.
This fixes building libc++ for msvcrt.dll, after the recent
changes in f1df976e39.
Signed-off-by: Martin Storsjö <martin@martin.st>
These functions and macros were added in MSVCR80.DLL and were not available
in MSVCRT.DLL from Windows XP.
This closes https://github.com/mingw-w64/mingw-w64/issues/60.
Signed-off-by: LIU Hao <lh_mouse@126.com>
For more D2DERR_* macros defined in d2derr.h, warnings is:
In file included from mingw-w64-headers/include/d2d1.h:20,
from mingw-w64-headers/include/d2d1_1.h:10,
from libsrc/uuid.c:29:
mingw-w64-headers/include/d2derr.h:16: warning: "D2DERR_BAD_NUMBER" redefined
#define D2DERR_BAD_NUMBER 0x88990011
In file included from mingw-w64-headers/include/winbase.h:2816,
from mingw-w64-headers/include/windows.h:70,
from mingw-w64-headers/include/rpc.h:16,
from mingw-w64-headers/include/credentialprovider.h:7,
from libsrc/uuid.c:17:
mingw-w64-headers/include/winerror.h:4713: note: this is the location of the previous definition
#define D2DERR_BAD_NUMBER _HRESULT_TYPEDEF_(0x88990011)
Add guards in winerror.h and d2derr.h to not define same macros multiple times.
Signed-off-by: LIU Hao <lh_mouse@126.com>
This fixes the following compiler error with gecko.
mozilla-unified/widget/windows/ToastNotification.cpp:832:14: error: no matching member function for call to 'Set'
832 | hr = aumid.Set(mAumid.ref().get());
| ~~~~~~^~~
corewrappers.h:58:25: note: candidate function not viable: no known conversion from
'typename raw_type<char16_t, int>::type' (aka 'char16ptr_t') to 'const HSTRING' (aka 'HSTRING__ *const') for 1st argument
corewrappers.h:53:25: note: candidate function not viable: requires 2 arguments, but 1 was provided
Signed-off-by: Biswapriyo Nath <nathbappai@gmail.com>
Signed-off-by: LIU Hao <lh_mouse@126.com>
When __CRT__NO_INLINE is enabled then ftime function ignored the
_USE_32BIT_TIME_T settings.
Fix this problem by declaring ftime function with __MINGW_ASM_CALL
attribute with correct alias based on _USE_32BIT_TIME_T settings.
With this change the inline variant of ftime function is not needed
anymore as it was just wrapper around aliased function, which is now
correctly resolved via __MINGW_ASM_CALL.
Signed-off-by: Martin Storsjö <martin@martin.st>
These functions return pointer to global variables with same name but
without the first leading underscore. These functions are available also
under name with leading "__p" prefix.
Functions __daylight(), __dstbias(), __timezone() and __tzname() are
available in msvcr80+ libraries and also in UCRT.
Functions __daylight(), __dstbias() are also available in later versions of
i386 and x64 msvcrt.dll and are available in all ARM versions of msvcrt.dll.
Functions __p__daylight(), __p__timezone() and __p__tzname() are available
since msvcrt20.dll and are present in all later msvcrt versions except the
UCRT and non-i386 OS system version of msvcrt.dll.
Function __p__dstbias() is available since msvcrt40.dll and is present also
in all later msvcrt versions except the UCRT and non-i386 OS system version
of msvcrt.dll.
Global variables _daylight, _timezone and _tzname are available in all
msvcrt versions except UCRT.
Global variable _dstbias is present since msvcrt40.dll, except UCRT and
non-i386 OS system versions of msvcrt.dll.
Define __daylight, __dstbias, __timezone and __tzname for all CRT import
libraries either as aliases to __p__daylight, __p__dstbias, __p__timezone,
and __p__tzname or as function wrappers around variables _daylight,
_dstbias, _timezone and _tzname, based on what each DLL library provides.
With this change also unifies time.h file to define _daylight, _dstbias,
_timezone and _tzname for all CRT builds via functions. This removes
another ifdef _UCRT and improves ABI compatibility between UCRT and
non-UCRT builds.
Signed-off-by: Martin Storsjö <martin@martin.st>
This avoids having to rely on inline functions for capturing
the variable arguments into a va_list and passing it to the
other v- prefixed function.
For the inline functions, in C++ we used plain C++ inline, while
we use static inline in C. (We need to use non-static inline in
C++ mode, for C++ module builds, where such stdio functions are
reexported by the C++ module.)
Using non-static inline functions can cause conflicts, if some
object files are built with __USE_MINGW_ANSI_STDIO enabled, and
others with it disabled. In such a case, both object files would
define a global comdat symbol e.g. "wprintf", and the linker would
pick either definition and use for all callers.
By redirecting the symbols with asm(), via __MINGW_ASM_CALL, there's
no conflict.
This also fixes https://github.com/mstorsjo/llvm-mingw/issues/438:
The fact that the inlines are non-static in C++ mode also can
cause other problems. The inline functions redirect towards the
__mingw_*printf functions, which do the formatting, and finally
call __ms_fwprintf to do the outputting. With short import libraries,
the import library redirect from __ms_fwprintf towards the imported
function fwprintf, is handled with a weak alias. But as we already
had a nonstatic function "fwprintf" (the inline function), this gets
linked and used instead of actually importing the "fwprintf" function
from msvcrt.dll.
By not using an inline function for the toplevel redirect, it doesn't
interfere with the import library __ms_fwprintf alias.
This doesn't seem to have been an issue for regular fprintf, as those
inline functions aren't wrapped in extern "C" {}, which causes the
inline function to get mangled differently, avoiding that problem.
Signed-off-by: Martin Storsjö <martin@martin.st>
