MS documentation for _onexit function says:
In the case when _onexit is called from within a DLL, routines registered
with _onexit run when the DLL is unloaded, after DllMain is called with
DLL_PROCESS_DETACH.
And for this functionality msvc statically links _onexit functionality for
DLL builds, and do not let applications to use msvcrt.dll's _onexit symbol
directly.
Fix this issue in mingw-w64 by redefining _onexit function to calls private
mingw-w64 atexit() function, which already distinguish between EXE and DLL
builds. Include this _onexit function into every CRT import library and
disable original _onexit symbol in all def files.
Signed-off-by: Martin Storsjö <martin@martin.st>
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>
This simplify symbol definition and move it to the common place into
crt-aliases.def.in file where are also other symbol aliases.
Signed-off-by: Martin Storsjö <martin@martin.st>
File msvcrtd.def.in contains only symbols from Microsoft Visual C++ 6.0
version of msvcrtd.dll as opposite of msvcrt.def.in which contains also
other symbols available in later OS system versions of msvcrt.dll versions.
There is no OS system versions of msvcrtd.dll.
File msvcrt.def.in already contains 64-bit fixed size and time function
aliases which are defined per-architecture, as msvcrt.dll contains
different set of symbols for different architectures, and so cannot use
some common aliases from include file crt-aliases.def.in.
On the other hand, msvcrtd.dll is i386-only library, fixed to VC++ 6.0
version and can use all common aliases from crt-aliases.def.in.
Currently msvcrtd.def.in do not have defined custom 64-bit fixed size and
time function aliases and neither from crt-aliases.def.in file. Fix this
problem and enable these aliases from crt-aliases.def.in file.
This change allows to use functions like _findfirst32(), _fstat32() or
_ctime32() in applications linking with msvcrtd.dll library.
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>
For these cases, we already had a declaration with asm() for use with
the fortify inline function; use the same declaration when not using
fortify too, to simplify things.
Add the missing format attributes on these declarations.
Signed-off-by: Martin Storsjö <martin@martin.st>
This avoids having to rely on inline functions.
Most of these are function calls that call another function with
exactly the same signature, these work well with a plain rename
with asm().
Some of them are cases where we used to call the more generalized
function inline, e.g. vscanf() calling __mingw_vfscanf, with
the first parameter hardcoded to stdin. When switching this to use
an asm() rename, this ends up calling __mingw_vscanf instead.
This is the case for __mingw_vscanf, __mingw_vprintf,
__mingw_vwscanf and __mingw_vwprintf; we already do have such
symbols in libmingwex.a even if they weren't actually ever
exercised before.
Signed-off-by: Martin Storsjö <martin@martin.st>
This avoids having to rely on inline functions.
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.
Signed-off-by: Martin Storsjö <martin@martin.st>
Modern GCC and Clang warn for these casts, with warnings like these:
../secapi/_chsize_s.c:20:6: warning: cast from 'FARPROC' (aka 'long long (*)()') to 'errno_t ((*))(int, long long) __attribute__((cdecl))' (aka 'int (*)(int, lo
ng long)') converts to incompatible function type [-Wcast-function-type-mismatch]
20 | f = (errno_t __cdecl (*)(int, long long))
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
21 | GetProcAddress (__mingw_get_msvcrt_handle (), "_chsize_s");
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
By casting to (void*) instead, we can let the compiler do the second
cast to the target function type implicitly, and also silencing these
warnings.
Signed-off-by: Martin Storsjö <martin@martin.st>
If the mingw-w64 headers are included in a way that doesn't mute
warnings in system headers, this header causes lots of warnings like:
warning: this use of "defined" may not be portable
It is caused by the fact that this macro __INTRINSIC_PROLOG uses
non-portable Conditional inclusion (ISO WG14 N2176 (C17) 6.10.1/4).
Disable this gcc warning via localized GCC pragmas to prevent 300 lines of
warnings for every application.
Signed-off-by: Martin Storsjö <martin@martin.st>
_osplatform is available only in i386 and x64 versions of msvcrt.dll,
msvcr70.dll, msvcr71.dll and msvcr80.dll.
Include emulation of __p__osplatform() functions for all other CRT
libraries, including UCRT.
Signed-off-by: Martin Storsjö <martin@martin.st>
_osver, _winmajor, _winminor and _winver are exported from CRT DLL library
up to the msvcr80.dll version. Add support for __p_ functions also for
msvcr90+ and UCRT import libraries.
Signed-off-by: Martin Storsjö <martin@martin.st>
ARM32 and ARM64 OS system version of msvcrt.dll do not have neither _winver
global variable, nor __p__winver() function. But they have _winmajor and
_winminor global variables.
Provide __p__winver() function emulation for ARM msvcrt import library via
via values of _winmajor and _winminor global variables.
Signed-off-by: Martin Storsjö <martin@martin.st>
Global variable _osplatform for i386 is provided in new versions of
msvcrt.dll and then also in msvcr70.dll, msvcr71.dll and msvcr80.dll.
For x64 it is provided in all msvcrt.dll and msvcr80.dll versions.
Function __p__osplatform() which returns pointer to global variable
_osplatform is provided only in i386 and x64 versions of msvcr80.dll.
On ARM systems there is no _osplatform platform variable and neither
__p__osplatform() function. UCRT does not provide them for any arch.
Provide missing function __p__osplatform() for i386 and x64 versions of
msvcrt.dll, then for i386 msvcr70.dll and msvcr71.dll and change definition
of _osplatform in header file to use __p__osplatform() function.
This aligns definition with msvc and avoid referencing another global
variable from mingw-w64 header files.
Signed-off-by: Martin Storsjö <martin@martin.st>
crtdll.dll's struct _stat is different than msvcrt.dll's struct _stat.
crtdll.dll's dev_t type (used in struct _stat) is short but msvcrt.dll's
dev_t type is unsigned int.
Fix this problem by providing mingw-w64 _stat32() and _fstat32() compatible
wrappers around crtdll.dll's _stat() and _fstat() functions. And then
redefining _stat, _fstat and fstat symbol aliases to the wrapper functions.
Advantage of this approach over adding #ifdef for crtdll builds into header
file for dev_t type is ABI compatibility between crtdll builds and other
CRT builds, at the expense of a bit more glue code in crtdll.dll import
library.
Note that mingw-w64 already provides custom stat() implantation which calls
_stat32() and therefore it already resolves to the correct function. No
need to update stat() function or its alias.
This change makes it possible to use stat functions from mingw-w64 header
files also with crtdll.dll library (via wrappers in crtdll import library).
Signed-off-by: Martin Storsjö <martin@martin.st>
gcc 8+ throws warning during imaxdiv.c compilation:
misc/imaxdiv.c:34:1: warning: ‘lldiv’ alias between functions of incompatible types ‘lldiv_t(long long int, long long int)’ {aka ‘struct <anonymous>(long long int, long long int)’} and ‘imaxdiv_t(intmax_t, intmax_t)’ {aka ‘struct <anonymous>(long long int, long long int)’} [-Wattribute-alias]
lldiv (long long, long long);
^~~~~
misc/imaxdiv.c:23:1: note: aliased declaration here
imaxdiv(intmax_t numer, intmax_t denom)
lldiv_t and imaxdiv_t structures are compatible, they have same members,
just defined for each function separately. This is how they are defined
also in MS VC++ header files.
Warning could be avoided by using typedef between structures, but this may
cause problems for C++ applications which overloaded functions which have
lldiv_t or imaxdiv_t parameters.
So rather locally disable this warning for gcc. Current code should be OK.
Signed-off-by: Martin Storsjö <martin@martin.st>
1. Remove trailing whitespace.
2. Silence warnings about conversion between function pointers.
3. Silence warnings about unused parameters.
4. For 64-bit targets, parse handle values as 64-bit integers.
5. Handle `WM_ACTIVATE` properly. Previously it fell through to `WM_MOUSEMOVE`
which worked by accident.
Reference: https://learn.microsoft.com/en-us/windows/win32/api/scrnsave/nf-scrnsave-defscreensaverproc
Signed-off-by: LIU Hao <lh_mouse@126.com>
When casting from function pointer which takes some parameters and returns
void to function pointer which returns non-void and may take some
parameters, then gcc throws following warning:
warning: wspiapi.h:50:20: warning: cast between incompatible function types from ‘void (__attribute__((stdcall)) *)(struct addrinfo *)’ to ‘int (__attribute__((stdcall)) *)()’ [-Wcast-function-type]
Avoid this warning by first casting to (void(*)(void)) pointer and then to
final (FARPROC) function pointer. Casting from and to (void(*)(void)) gcc
and clang does not throw incompatible cast warnings.
See: https://gcc.gnu.org/gcc-14/porting_to.html#incompatible-pointer-types
Signed-off-by: Martin Storsjö <martin@martin.st>
_osver, _winmajor, _winminor and _winver global variables are available
since the first crtdll.dll library up to the msvcr80.dll (both i386 and
x64), including OS system version of msvcrt.dll. ARM versions of msvcrt.dll
is missing _winver variable (but others are present). __p_ functions which
return pointers to these variables are missing just in crtdll.dll,
msvcrt10.dll and non-i386 versions of msvcrt.dll.
Provide missing __p_ functions for libraries which provides global
variables and defines _osver, _winmajor, _winminor and _winver via
__p_ functions in header files.
This aligns definitions of these version macros with msvc (which also
defines them via __p_ functions) and also with other definitions in
mingw-w64 header files (which also use __p_ functions instead of global
__MINGW_IMP_SYMBOL).
Signed-off-by: Martin Storsjö <martin@martin.st>
In file msvcrt.def.in is mentioned that symbol __p__iob is provided by
mingw-w64 emulation. But it is not yet. Functions __p__iob() and
__iob_func() returns same pointer to first member of _iob[] array, so
define __p__iob symbol for non-i386 builds as alias to __iob_func symbol.
Symbol __iob_func is present in all non-i386 versions of msvcrt.dll
library.
Signed-off-by: Martin Storsjö <martin@martin.st>
In file msvcrt.def.in is mentioned that symbols __p___mb_cur_max,
__p__pctype and __p__pwctype are provided by mingw-w64 emulation, but
source files which provide them are missing in Makefile.am sections for
building msvcrt.dll import libraries. Fix this problem.
Signed-off-by: Martin Storsjö <martin@martin.st>
Test case:
#include <math.h>
int isnan_wrapper(double value) { return isnan(value); }
Output:
$ g++ -Wconversion -c snippet.cpp
warning: conversion to 'float' from 'double' may alter its value
warning: conversion to 'int' from 'double' may alter its value
First warning is caused by the fact in C++ mode __mingw_choose_expr is
using ternary operator and warning is triggered also by the case which is
not executed.
Second warning is caused by the fact that type of expression
(__builtin_trap(),x) for isnan(x) is double, but return value of
isnan_wrapper() is int. But this expression never returns.
Fix the first problem to use explicit cast for __isnan* calls which
correspondents to matched __mingw_types_compatible_p types.
And fix second problem by changing expression to something which has type
of int.
Bug: https://sourceforge.net/p/mingw-w64/bugs/481/
Signed-off-by: LIU Hao <lh_mouse@126.com>
Windres makes no use of SSE intrinsics, but produces warnings:
C:/MSYS64/mingw32/lib/gcc/i686-w64-mingw32/14.2.1/include/xmmintrin.h:126: digit exceeds base
126 | return __extension__ (__m128){ 0.0f, 0.0f, 0.0f, 0.0f };
Reference: https://gitlab.gnome.org/GNOME/gimp/-/issues/11655
Signed-off-by: LIU Hao <lh_mouse@126.com>
mingw-w64 startup code already provides its own atexit() functions.
Implementation for DLL and EXE builds differs because version for DLL
builds has to be called at the time when unloading DLL library whereas
version for EXE builds is called at process termination. DLL version of
atexit() stores atexit's function pointers into own table which is called
from DLL unload hook. EXE version just calls CRT's _onexit() function.
Some msvcrt def files provide atexit function symbol without DATA keyword,
which is than exported from msvcrt import library. And so it conflicts with
the atexit symbol from startup file and makes atexit function unusable.
UCRT libraries do not have this problem because they provide atexit
function under different name _crt_atexit.
Fix msvcrt symbol conflicts by renaming atexit function to _crt_atexit in
every CRT def file. This will ensure compatibility with UCRT and also that
applications would call atexit function from mingw-w64 startup file and not
from CRT import library.
Also change atexit implementation in exe startup file to directly call
_crt_atexit() function instead of _onexit(). This will simplify usage as
UCRT does not have _onexit() function (mingw-w64 provides only _onexit
wrapper around _crt_atexit) and msvcrt's atexit() function (renamed to
_crt_atexit() in def file) is doing same thing as msvcrt _onexit().
Signed-off-by: Jacek Caban <jacek@codeweavers.com>
Here is a patch which fixes bugs #988 and #992 following the commit
7b3379.
This commit introduced a new function winpthreads_init in charge of
setting up the _pthread_get_system_time_best_as_file_time and _pthread_get_tick_count_64
pointers using a runtime detection.
This function is defined with the constructor attribute. The problem is
that every static object making use of a constructor is also tagged with
this constructor attribute and the call ordering is unspecified.
For example, when linking code making use of C++11 chrono objects the
libstdc++ code is called before winpthreads_init but makes of the
clock_gettime function which causes a crash.
A minimal reproduction code can be found here in bug #992.
This bug can be fixed by setting a priority of 0 to the
winpthreads_constructor. It is then called before the static
constructors.
Signed-off-by: LIU Hao <lh_mouse@126.com>
DWMAPI was already defined by dwmapi.h, but it was not actually used
when declaring the functions in that header, so they were missing
DECLSPEC_IMPORT.
This patch replaces HRESULT WINAPI with DWMAPI, and WINBOOL WINAPI with
DWMAPI_(WINBOOL) for the DwmDefWindowProc function that does not return
HRESULT.
Signed-off-by: Daniel Verkamp <daniel@drv.nu>
Signed-off-by: LIU Hao <lh_mouse@126.com>
