Re: [Mingw-w64-public] [PATCH] crt: Avoid warnings about ucrt _scprintf/_snprintf/_snscanf missing a prototype
On Tue, 21 May 2024, LIU Hao wrote: 在 2024-05-21 19:27, Martin Storsjö 写道: Signed-off-by: Martin Storsjö --- mingw-w64-crt/stdio/ucrt__scprintf.c | 2 -- mingw-w64-crt/stdio/ucrt__snprintf.c | 2 -- mingw-w64-crt/stdio/ucrt__snscanf.c | 2 -- 3 files changed, 6 deletions(-) LGTM. Thanks. Thanks, pushed. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH] crt: Avoid warnings about ucrt _scprintf/_snprintf/_snscanf missing a prototype
Signed-off-by: Martin Storsjö
---
mingw-w64-crt/stdio/ucrt__scprintf.c | 2 --
mingw-w64-crt/stdio/ucrt__snprintf.c | 2 --
mingw-w64-crt/stdio/ucrt__snscanf.c | 2 --
3 files changed, 6 deletions(-)
diff --git a/mingw-w64-crt/stdio/ucrt__scprintf.c
b/mingw-w64-crt/stdio/ucrt__scprintf.c
index 285d32017..bae7d6016 100644
--- a/mingw-w64-crt/stdio/ucrt__scprintf.c
+++ b/mingw-w64-crt/stdio/ucrt__scprintf.c
@@ -6,10 +6,8 @@
#undef __MSVCRT_VERSION__
#define _UCRT
-#define _scprintf real__scprintf
#include
#include
-#undef _scprintf
int __cdecl _scprintf(const char * __restrict__ _Format, ...)
{
diff --git a/mingw-w64-crt/stdio/ucrt__snprintf.c
b/mingw-w64-crt/stdio/ucrt__snprintf.c
index 9a43846f3..8aec32612 100644
--- a/mingw-w64-crt/stdio/ucrt__snprintf.c
+++ b/mingw-w64-crt/stdio/ucrt__snprintf.c
@@ -6,10 +6,8 @@
#undef __MSVCRT_VERSION__
#define _UCRT
-#define _snprintf real__snprintf
#include
#include
-#undef _snprintf
int __cdecl _snprintf(char * __restrict__ _Dest, size_t _Count, const char *
__restrict__ _Format, ...)
{
diff --git a/mingw-w64-crt/stdio/ucrt__snscanf.c
b/mingw-w64-crt/stdio/ucrt__snscanf.c
index 43c64efad..341b0e5ad 100644
--- a/mingw-w64-crt/stdio/ucrt__snscanf.c
+++ b/mingw-w64-crt/stdio/ucrt__snscanf.c
@@ -6,10 +6,8 @@
#undef __MSVCRT_VERSION__
#define _UCRT
-#define _snscanf real__snscanf
#include
#include
-#undef _snscanf
int __cdecl _snscanf(const char * __restrict__ _Src, size_t _MaxCount, const
char * __restrict__ _Format, ...)
{
--
2.34.1
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 6/9] crt: Fix DATA aliases for crtdll.dll
On Mon, 20 May 2024, Pali Rohár wrote: On Monday 20 May 2024 13:07:29 Martin Storsjö wrote: On Thu, 9 May 2024, Pali Rohár wrote: crtdll.dll library has some DATA symbols with _dll suffix. Fix generating aliases for these symbols. --- .../def-include/msvcrt-common.def.in | 23 +++ mingw-w64-crt/lib32/crtdll.def.in | 1 + 2 files changed, 24 insertions(+) diff --git a/mingw-w64-crt/def-include/msvcrt-common.def.in b/mingw-w64-crt/def-include/msvcrt-common.def.in index 125982d5bf53..98ab6d6b62f8 100644 --- a/mingw-w64-crt/def-include/msvcrt-common.def.in +++ b/mingw-w64-crt/def-include/msvcrt-common.def.in @@ -2,6 +2,7 @@ #define ADD_UNDERSCORE(symbol) symbol == _ ## symbol #define ADD_UNDERSCORE_DATA(symbol) symbol DATA == _ ## symbol +#define ADD_UNDERSCORE_DATA_DLL(symbol) symbol DATA == _ ## symbol ## _dll #define ADD_DOUBLE_UNDERSCORE(symbol) symbol == __ ## symbol ; This is list of symbol aliases from the Visual C++ 1.0 oldnames.lib library @@ -22,14 +23,22 @@ ADD_UNDERSCORE(creat) ; ADD_UNDERSCORE(cscanf) ADD_UNDERSCORE(cwait) #ifndef UCRTBASE +#ifdef CRTDLL +ADD_UNDERSCORE_DATA_DLL(daylight) +#else ADD_UNDERSCORE_DATA(daylight) #endif +#endif Instead of nesting these ifdefs, I think this would be clearer like this: #ifdef CRTDLL ... #elif !defined(UCRTBASE) ... #endif This seems to be the case for a couple of the other changes as well, but the last ifdef, around sys_errlist and sys_nerr, probably is best to keep as is here. // Martin That makes sense. Now I looked at it and I'm proposing following change which also documents why those symbols are skipped for UCRT: This looks good, thanks! I applied the rest of these patches with these suggestions then, thanks! // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 2/9] crt: Include msvcrt-common.def.in after declaring all library symbols
On Mon, 20 May 2024, Pali Rohár wrote: On Monday 20 May 2024 13:04:33 Martin Storsjö wrote: On Thu, 9 May 2024, Pali Rohár wrote: File msvcrt-common.def.in adds just symbol aliases, so include it in CRT def files after having all symbols declared. Note that some def files use DECORATED_EXPORT macro from func.def.in file, so include func.def.in at beginning of each def file. I guess def files also could use many other of the macros defined in func.def.in, like F32(), F64() etc - not only DECORATED_EXPORT? (Not sure if this is done in practice or not though.) // Martin That it truth. For example msvcrt.def.in uses also other macros from func.def.in file. So what about rephrasing commit message to something like this? Note that some def files use macros from func.def.in file, so include func.def.in at beginning of the file when needed. This sounds good to me, thanks! // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] crt: crtdll.def.in: Fix library name and time symbol exports
On Sun, 12 May 2024, Pali Rohár wrote: Change library name to uppercase CRTDLL.dll and remove DATA keyword for all time function symbols. This is how the original crtdll.dll library is defined. --- mingw-w64-crt/lib32/crtdll.def.in | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) These three patches seemed fine, so I pushed them. Thanks! // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] crt: msvcr80.dll: Remove duplicated X64 fallback functions
On Thu, 9 May 2024, Pali Rohár wrote: Symbols __p___argv, __p__acmdln, __p__commode, __p__fmode, and __p__wcmdln are available in X64 version of msvcr80.dll. This was clarified and fixed in commit e0426704cce399a7517e4ec71360bbd1d5f880e3. So remove duplicated definitions of fallback functions. --- mingw-w64-crt/Makefile.am | 9 + 1 file changed, 1 insertion(+), 8 deletions(-) This looks ok to me, and is independent of the other patches, so I pushed it. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 3/3] crt: msvcrt.def.in: Move arch-specific comments in #ifdef sections
On Thu, 9 May 2024, Pali Rohár wrote: So comments unrelated to processing architecture would be dropped by preprocessor. --- mingw-w64-crt/lib-common/msvcrt.def.in | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) This set of three patches looks ok to me, but depends on parts of the earlier 9-patch set, so it needs to wait for that one to be applied. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 9/9] crt: Rename msvcrt-common.def.in to crt-aliases.def.in
On Thu, 9 May 2024, Pali Rohár wrote: This file contains definitions of symbol aliases for any CRT library. It is already used by msvcrt, crtdll and ucrt. So rename msvcrt-common.def.in to crt-aliases.def.in as new name better match the purpose of the file. --- The rest of these 9 patches seem fine to me, the only details I noticed was some parts of the commit message in 2/9 and ifdef style in 6/9. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 6/9] crt: Fix DATA aliases for crtdll.dll
On Thu, 9 May 2024, Pali Rohár wrote: crtdll.dll library has some DATA symbols with _dll suffix. Fix generating aliases for these symbols. --- .../def-include/msvcrt-common.def.in | 23 +++ mingw-w64-crt/lib32/crtdll.def.in | 1 + 2 files changed, 24 insertions(+) diff --git a/mingw-w64-crt/def-include/msvcrt-common.def.in b/mingw-w64-crt/def-include/msvcrt-common.def.in index 125982d5bf53..98ab6d6b62f8 100644 --- a/mingw-w64-crt/def-include/msvcrt-common.def.in +++ b/mingw-w64-crt/def-include/msvcrt-common.def.in @@ -2,6 +2,7 @@ #define ADD_UNDERSCORE(symbol) symbol == _ ## symbol #define ADD_UNDERSCORE_DATA(symbol) symbol DATA == _ ## symbol +#define ADD_UNDERSCORE_DATA_DLL(symbol) symbol DATA == _ ## symbol ## _dll #define ADD_DOUBLE_UNDERSCORE(symbol) symbol == __ ## symbol ; This is list of symbol aliases from the Visual C++ 1.0 oldnames.lib library @@ -22,14 +23,22 @@ ADD_UNDERSCORE(creat) ; ADD_UNDERSCORE(cscanf) ADD_UNDERSCORE(cwait) #ifndef UCRTBASE +#ifdef CRTDLL +ADD_UNDERSCORE_DATA_DLL(daylight) +#else ADD_UNDERSCORE_DATA(daylight) #endif +#endif Instead of nesting these ifdefs, I think this would be clearer like this: #ifdef CRTDLL ... #elif !defined(UCRTBASE) ... #endif This seems to be the case for a couple of the other changes as well, but the last ifdef, around sys_errlist and sys_nerr, probably is best to keep as is here. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 2/9] crt: Include msvcrt-common.def.in after declaring all library symbols
On Thu, 9 May 2024, Pali Rohár wrote: File msvcrt-common.def.in adds just symbol aliases, so include it in CRT def files after having all symbols declared. Note that some def files use DECORATED_EXPORT macro from func.def.in file, so include func.def.in at beginning of each def file. I guess def files also could use many other of the macros defined in func.def.in, like F32(), F64() etc - not only DECORATED_EXPORT? (Not sure if this is done in practice or not though.) // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 1/3] crt: msvcrt.def.in: Fix definitions of _ctype and _mbcasemap symbols
On Fri, 17 May 2024, Pali Rohár wrote: Hello, have you looked at this and other changes? Not yet - I'll try to get around to it soon. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH v2 1/3] headers: Use the __MINGW_(MS|GNU)_(PRINTF|SCANF) macros
On Fri, 17 May 2024, LIU Hao wrote: 在 2024-05-17 08:11, Jacek Caban 写道: Hi, The series looks good to me. LGTM, too. Thanks, pushed now. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] include/minwinbase: Fix enumerators of `FILE_INFO_BY_HANDLE_CLASS`
On Wed, 15 May 2024, LIU Hao wrote: -- LGTM, thanks! // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH v2 1/3] headers: Use the __MINGW_(MS|GNU)_(PRINTF|SCANF) macros
Prefer declaring these attributes with such macros, rather than spelling out the full attribute. These macros were added in 73e50d0577c2111a1810b21de8d61022dbbf2411 in 2013, but haven't been used in mingw-w64 headers since (although they may have been used in user code). These macros, which expand to the full attribute, differ slightly from the other preexisting macros (which are used quite widely) like __MINGW_PRINTF_FORMAT, which expand only to the type string "gnu_printf", "ms_printf" or "printf". However as we do have these existing macros in this form, for declaring a specific form of these format attributes, take them into use where applicable. Signed-off-by: Martin Storsjö --- No changes to this patch. --- mingw-w64-headers/crt/stdio.h | 140 +- 1 file changed, 70 insertions(+), 70 deletions(-) diff --git a/mingw-w64-headers/crt/stdio.h b/mingw-w64-headers/crt/stdio.h index d9fb00498..60c83b94e 100644 --- a/mingw-w64-headers/crt/stdio.h +++ b/mingw-w64-headers/crt/stdio.h @@ -165,83 +165,83 @@ __mingw_bos_declare; #ifndef _STDIO_DEFINED extern - __attribute__((__format__ (gnu_scanf, 2, 3))) __MINGW_ATTRIB_NONNULL(2) + __MINGW_GNU_SCANF(2, 3) __MINGW_ATTRIB_NONNULL(2) int __cdecl __mingw_sscanf(const char * __restrict__ _Src,const char * __restrict__ _Format,...); extern - __attribute__((__format__ (gnu_scanf, 2, 0))) __MINGW_ATTRIB_NONNULL(2) + __MINGW_GNU_SCANF(2, 0) __MINGW_ATTRIB_NONNULL(2) int __cdecl __mingw_vsscanf (const char * __restrict__ _Str,const char * __restrict__ Format,va_list argp); extern - __attribute__((__format__ (gnu_scanf, 1, 2))) __MINGW_ATTRIB_NONNULL(1) + __MINGW_GNU_SCANF(1, 2) __MINGW_ATTRIB_NONNULL(1) int __cdecl __mingw_scanf(const char * __restrict__ _Format,...); extern - __attribute__((__format__ (gnu_scanf, 1, 0))) __MINGW_ATTRIB_NONNULL(1) + __MINGW_GNU_SCANF(1, 0) __MINGW_ATTRIB_NONNULL(1) int __cdecl __mingw_vscanf(const char * __restrict__ Format, va_list argp); extern - __attribute__((__format__ (gnu_scanf, 2, 3))) __MINGW_ATTRIB_NONNULL(2) + __MINGW_GNU_SCANF(2, 3) __MINGW_ATTRIB_NONNULL(2) int __cdecl __mingw_fscanf(FILE * __restrict__ _File,const char * __restrict__ _Format,...); extern - __attribute__((__format__ (gnu_scanf, 2, 0))) __MINGW_ATTRIB_NONNULL(2) + __MINGW_GNU_SCANF(2, 0) __MINGW_ATTRIB_NONNULL(2) int __cdecl __mingw_vfscanf (FILE * __restrict__ fp, const char * __restrict__ Format,va_list argp); extern - __attribute__((__format__ (gnu_printf, 3, 0))) __MINGW_ATTRIB_NONNULL(3) + __MINGW_GNU_PRINTF(3, 0) __MINGW_ATTRIB_NONNULL(3) int __cdecl __mingw_vsnprintf(char * __restrict__ _DstBuf,size_t _MaxCount,const char * __restrict__ _Format, va_list _ArgList); extern - __attribute__((__format__ (gnu_printf, 3, 4))) __MINGW_ATTRIB_NONNULL(3) + __MINGW_GNU_PRINTF(3, 4) __MINGW_ATTRIB_NONNULL(3) int __cdecl __mingw_snprintf(char * __restrict__ s, size_t n, const char * __restrict__ format, ...); extern - __attribute__((__format__ (gnu_printf, 1, 2))) __MINGW_ATTRIB_NONNULL(1) + __MINGW_GNU_PRINTF(1, 2) __MINGW_ATTRIB_NONNULL(1) int __cdecl __mingw_printf(const char * __restrict__ , ... ) __MINGW_NOTHROW; extern - __attribute__((__format__ (gnu_printf, 1, 0))) __MINGW_ATTRIB_NONNULL(1) + __MINGW_GNU_PRINTF(1, 0) __MINGW_ATTRIB_NONNULL(1) int __cdecl __mingw_vprintf (const char * __restrict__ , va_list) __MINGW_NOTHROW; extern - __attribute__((__format__ (gnu_printf, 2, 3))) __MINGW_ATTRIB_NONNULL(2) + __MINGW_GNU_PRINTF(2, 3) __MINGW_ATTRIB_NONNULL(2) int __cdecl __mingw_fprintf (FILE * __restrict__ , const char * __restrict__ , ...) __MINGW_NOTHROW; extern - __attribute__((__format__ (gnu_printf, 2, 0))) __MINGW_ATTRIB_NONNULL(2) + __MINGW_GNU_PRINTF(2, 0) __MINGW_ATTRIB_NONNULL(2) int __cdecl __mingw_vfprintf (FILE * __restrict__ , const char * __restrict__ , va_list) __MINGW_NOTHROW; extern - __attribute__((__format__ (gnu_printf, 2, 3))) __MINGW_ATTRIB_NONNULL(2) + __MINGW_GNU_PRINTF(2, 3) __MINGW_ATTRIB_NONNULL(2) int __cdecl __mingw_sprintf (char * __restrict__ , const char * __restrict__ , ...) __MINGW_NOTHROW; extern - __attribute__((__format__ (gnu_printf, 2, 0))) __MINGW_ATTRIB_NONNULL(2) + __MINGW_GNU_PRINTF(2, 0) __MINGW_ATTRIB_NONNULL(2) int __cdecl __mingw_vsprintf (char * __restrict__ , const char * __restrict__ , va_list) __MINGW_NOTHROW; extern - __attribute__((__format__ (gnu_printf, 2, 3))) __attribute__((nonnull (1,2))) + __MINGW_GNU_PRINTF(2, 3) __attribute__((nonnull (1,2))) int __cdecl __mingw_asprintf(char ** __restrict__ , const char * __restrict__ , ...) __MINGW_NOTHROW; extern - __attribute__((__format__ (gnu_printf, 2, 0))) __attribute__((nonnull (1,2))) + __MINGW_GNU_PRINTF(2, 0) __attribute__((nonnull (1,2))) int __cdecl __mingw_vasprintf(char ** __restrict__ , const char * __restrict__ , va_list) __MINGW_NOTHR
[Mingw-w64-public] [PATCH v2 2/3] headers: Don't use the ms_printf/scanf and gnu_printf/scanf format attributes with clang
Clang doesn't support the ms_printf/scanf and gnu_printf/scanf format attributes, only plain "printf" and "scanf". We already expand e.g. __MINGW_PRINTF_FORMAT (which differs depending on __USE_MINGW_ANSI_STDIO) into plain "printf" for Clang, since 015e637b4b24d9915162ab877ed539ad0e657951. However, a number of functions explicitly declared either gnu or ms style formats, which caused these functions to not get any format string diagnostics. This fixes https://github.com/llvm/llvm-project/issues/68995, which reported that no warnings are produced for mismatched printf/scanf format strings, when compiling with Clang, with a toolchain targeting msvcrt (i.e. in practice using __USE_MINGW_ANSI_STDIO enabled). Signed-off-by: Martin Storsjö --- Changed to use __printf__/__scanf__. --- mingw-w64-headers/crt/_mingw_mac.h | 14 ++ 1 file changed, 14 insertions(+) diff --git a/mingw-w64-headers/crt/_mingw_mac.h b/mingw-w64-headers/crt/_mingw_mac.h index 9de143e5d..532be1381 100644 --- a/mingw-w64-headers/crt/_mingw_mac.h +++ b/mingw-w64-headers/crt/_mingw_mac.h @@ -267,6 +267,19 @@ # define __MINGW_ATTRIB_DEPRECATED_SEC_WARN #endif +#ifdef __clang__ +#define __MINGW_MS_PRINTF(__format,__args) \ + __attribute__((__format__(__printf__, __format,__args))) + +#define __MINGW_MS_SCANF(__format,__args) \ + __attribute__((__format__(__scanf__, __format,__args))) + +#define __MINGW_GNU_PRINTF(__format,__args) \ + __attribute__((__format__(__printf__,__format,__args))) + +#define __MINGW_GNU_SCANF(__format,__args) \ + __attribute__((__format__(__scanf__, __format,__args))) +#else #define __MINGW_MS_PRINTF(__format,__args) \ __attribute__((__format__(ms_printf, __format,__args))) @@ -278,6 +291,7 @@ #define __MINGW_GNU_SCANF(__format,__args) \ __attribute__((__format__(gnu_scanf, __format,__args))) +#endif /* !__clang__ */ #undef __mingw_ovr -- 2.34.1 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH v2 3/3] headers: Use reserved name for printf/scanf format attribute types
Signed-off-by: Martin Storsjö --- This patch is new for v2 of the patchset. --- mingw-w64-headers/crt/_mingw_mac.h | 8 mingw-w64-headers/crt/stdio.h | 12 ++-- 2 files changed, 10 insertions(+), 10 deletions(-) diff --git a/mingw-w64-headers/crt/_mingw_mac.h b/mingw-w64-headers/crt/_mingw_mac.h index 532be1381..30ade2ebc 100644 --- a/mingw-w64-headers/crt/_mingw_mac.h +++ b/mingw-w64-headers/crt/_mingw_mac.h @@ -281,16 +281,16 @@ __attribute__((__format__(__scanf__, __format,__args))) #else #define __MINGW_MS_PRINTF(__format,__args) \ - __attribute__((__format__(ms_printf, __format,__args))) + __attribute__((__format__(__ms_printf__, __format,__args))) #define __MINGW_MS_SCANF(__format,__args) \ - __attribute__((__format__(ms_scanf, __format,__args))) + __attribute__((__format__(__ms_scanf__, __format,__args))) #define __MINGW_GNU_PRINTF(__format,__args) \ - __attribute__((__format__(gnu_printf,__format,__args))) + __attribute__((__format__(__gnu_printf__,__format,__args))) #define __MINGW_GNU_SCANF(__format,__args) \ - __attribute__((__format__(gnu_scanf, __format,__args))) + __attribute__((__format__(__gnu_scanf__, __format,__args))) #endif /* !__clang__ */ #undef __mingw_ovr diff --git a/mingw-w64-headers/crt/stdio.h b/mingw-w64-headers/crt/stdio.h index 60c83b94e..c22122c33 100644 --- a/mingw-w64-headers/crt/stdio.h +++ b/mingw-w64-headers/crt/stdio.h @@ -255,14 +255,14 @@ extern #undef __MINGW_SCANF_FORMAT #if defined(__clang__) -#define __MINGW_PRINTF_FORMAT printf -#define __MINGW_SCANF_FORMAT scanf +#define __MINGW_PRINTF_FORMAT __printf__ +#define __MINGW_SCANF_FORMAT __scanf__ #elif defined(_UCRT) || __USE_MINGW_ANSI_STDIO -#define __MINGW_PRINTF_FORMAT gnu_printf -#define __MINGW_SCANF_FORMAT gnu_scanf +#define __MINGW_PRINTF_FORMAT __gnu_printf__ +#define __MINGW_SCANF_FORMAT __gnu_scanf__ #else -#define __MINGW_PRINTF_FORMAT ms_printf -#define __MINGW_SCANF_FORMAT ms_scanf +#define __MINGW_PRINTF_FORMAT __ms_printf__ +#define __MINGW_SCANF_FORMAT __ms_scanf__ #endif #if __USE_MINGW_ANSI_STDIO && !defined(_CRTBLD) -- 2.34.1 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 2/2] headers: Don't use the ms_printf/scanf and gnu_printf/scanf format attributes with clang
On Thu, 16 May 2024, LIU Hao wrote: 在 2024-05-16 17:05, Martin Storsjö 写道: Clang doesn't support the ms_printf/scanf and gnu_printf/scanf format attributes, only plain "printf" and "scanf". We already expand e.g. __MINGW_PRINTF_FORMAT (which differs depending on __USE_MINGW_ANSI_STDIO) into plain "printf" for Clang, since 015e637b4b24d9915162ab877ed539ad0e657951. However, a number of functions explicitly declared either gnu or ms style formats, which caused these functions to not get any format string diagnostics. This fixes https://github.com/llvm/llvm-project/issues/68995, which reported that no warnings are produced for mismatched printf/scanf format strings, when compiling with Clang, with a toolchain targeting msvcrt (i.e. in practice using __USE_MINGW_ANSI_STDIO enabled). Signed-off-by: Martin Storsjö --- mingw-w64-headers/crt/_mingw_mac.h | 14 ++ 1 file changed, 14 insertions(+) diff --git a/mingw-w64-headers/crt/_mingw_mac.h b/mingw-w64-headers/crt/_mingw_mac.h index 9de143e5d..6c133d00e 100644 --- a/mingw-w64-headers/crt/_mingw_mac.h +++ b/mingw-w64-headers/crt/_mingw_mac.h @@ -267,6 +267,19 @@ # define __MINGW_ATTRIB_DEPRECATED_SEC_WARN #endif +#ifdef __clang__ +#define __MINGW_MS_PRINTF(__format,__args) \ + __attribute__((__format__(printf, __format,__args))) While this idea is reasonable; I would like to suggest changing __attribute__((__format__(printf, __format,__args))) to __attribute__((__format__(__printf__, __format, __args))) i.e. reserved names are to be used within standard headers. What do you think? Thanks, that's probably a good idea. I guess we should do the same change for gnu/ms_printf/scanf too, and for __MINGW_PRINTF_FORMAT, in a separate change. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH 1/2] headers: Use the __MINGW_(MS|GNU)_(PRINTF|SCANF) macros
Prefer declaring these attributes with such macros, rather than spelling out the full attribute. These macros were added in 73e50d0577c2111a1810b21de8d61022dbbf2411 in 2013, but haven't been used in mingw-w64 headers since (although they may have been used in user code). These macros, which expand to the full attribute, differ slightly from the other preexisting macros (which are used quite widely) like __MINGW_PRINTF_FORMAT, which expand only to the type string "gnu_printf", "ms_printf" or "printf". However as we do have these existing macros in this form, for declaring a specific form of these format attributes, take them into use where applicable. Signed-off-by: Martin Storsjö --- mingw-w64-headers/crt/stdio.h | 140 +- 1 file changed, 70 insertions(+), 70 deletions(-) diff --git a/mingw-w64-headers/crt/stdio.h b/mingw-w64-headers/crt/stdio.h index d9fb00498..60c83b94e 100644 --- a/mingw-w64-headers/crt/stdio.h +++ b/mingw-w64-headers/crt/stdio.h @@ -165,83 +165,83 @@ __mingw_bos_declare; #ifndef _STDIO_DEFINED extern - __attribute__((__format__ (gnu_scanf, 2, 3))) __MINGW_ATTRIB_NONNULL(2) + __MINGW_GNU_SCANF(2, 3) __MINGW_ATTRIB_NONNULL(2) int __cdecl __mingw_sscanf(const char * __restrict__ _Src,const char * __restrict__ _Format,...); extern - __attribute__((__format__ (gnu_scanf, 2, 0))) __MINGW_ATTRIB_NONNULL(2) + __MINGW_GNU_SCANF(2, 0) __MINGW_ATTRIB_NONNULL(2) int __cdecl __mingw_vsscanf (const char * __restrict__ _Str,const char * __restrict__ Format,va_list argp); extern - __attribute__((__format__ (gnu_scanf, 1, 2))) __MINGW_ATTRIB_NONNULL(1) + __MINGW_GNU_SCANF(1, 2) __MINGW_ATTRIB_NONNULL(1) int __cdecl __mingw_scanf(const char * __restrict__ _Format,...); extern - __attribute__((__format__ (gnu_scanf, 1, 0))) __MINGW_ATTRIB_NONNULL(1) + __MINGW_GNU_SCANF(1, 0) __MINGW_ATTRIB_NONNULL(1) int __cdecl __mingw_vscanf(const char * __restrict__ Format, va_list argp); extern - __attribute__((__format__ (gnu_scanf, 2, 3))) __MINGW_ATTRIB_NONNULL(2) + __MINGW_GNU_SCANF(2, 3) __MINGW_ATTRIB_NONNULL(2) int __cdecl __mingw_fscanf(FILE * __restrict__ _File,const char * __restrict__ _Format,...); extern - __attribute__((__format__ (gnu_scanf, 2, 0))) __MINGW_ATTRIB_NONNULL(2) + __MINGW_GNU_SCANF(2, 0) __MINGW_ATTRIB_NONNULL(2) int __cdecl __mingw_vfscanf (FILE * __restrict__ fp, const char * __restrict__ Format,va_list argp); extern - __attribute__((__format__ (gnu_printf, 3, 0))) __MINGW_ATTRIB_NONNULL(3) + __MINGW_GNU_PRINTF(3, 0) __MINGW_ATTRIB_NONNULL(3) int __cdecl __mingw_vsnprintf(char * __restrict__ _DstBuf,size_t _MaxCount,const char * __restrict__ _Format, va_list _ArgList); extern - __attribute__((__format__ (gnu_printf, 3, 4))) __MINGW_ATTRIB_NONNULL(3) + __MINGW_GNU_PRINTF(3, 4) __MINGW_ATTRIB_NONNULL(3) int __cdecl __mingw_snprintf(char * __restrict__ s, size_t n, const char * __restrict__ format, ...); extern - __attribute__((__format__ (gnu_printf, 1, 2))) __MINGW_ATTRIB_NONNULL(1) + __MINGW_GNU_PRINTF(1, 2) __MINGW_ATTRIB_NONNULL(1) int __cdecl __mingw_printf(const char * __restrict__ , ... ) __MINGW_NOTHROW; extern - __attribute__((__format__ (gnu_printf, 1, 0))) __MINGW_ATTRIB_NONNULL(1) + __MINGW_GNU_PRINTF(1, 0) __MINGW_ATTRIB_NONNULL(1) int __cdecl __mingw_vprintf (const char * __restrict__ , va_list) __MINGW_NOTHROW; extern - __attribute__((__format__ (gnu_printf, 2, 3))) __MINGW_ATTRIB_NONNULL(2) + __MINGW_GNU_PRINTF(2, 3) __MINGW_ATTRIB_NONNULL(2) int __cdecl __mingw_fprintf (FILE * __restrict__ , const char * __restrict__ , ...) __MINGW_NOTHROW; extern - __attribute__((__format__ (gnu_printf, 2, 0))) __MINGW_ATTRIB_NONNULL(2) + __MINGW_GNU_PRINTF(2, 0) __MINGW_ATTRIB_NONNULL(2) int __cdecl __mingw_vfprintf (FILE * __restrict__ , const char * __restrict__ , va_list) __MINGW_NOTHROW; extern - __attribute__((__format__ (gnu_printf, 2, 3))) __MINGW_ATTRIB_NONNULL(2) + __MINGW_GNU_PRINTF(2, 3) __MINGW_ATTRIB_NONNULL(2) int __cdecl __mingw_sprintf (char * __restrict__ , const char * __restrict__ , ...) __MINGW_NOTHROW; extern - __attribute__((__format__ (gnu_printf, 2, 0))) __MINGW_ATTRIB_NONNULL(2) + __MINGW_GNU_PRINTF(2, 0) __MINGW_ATTRIB_NONNULL(2) int __cdecl __mingw_vsprintf (char * __restrict__ , const char * __restrict__ , va_list) __MINGW_NOTHROW; extern - __attribute__((__format__ (gnu_printf, 2, 3))) __attribute__((nonnull (1,2))) + __MINGW_GNU_PRINTF(2, 3) __attribute__((nonnull (1,2))) int __cdecl __mingw_asprintf(char ** __restrict__ , const char * __restrict__ , ...) __MINGW_NOTHROW; extern - __attribute__((__format__ (gnu_printf, 2, 0))) __attribute__((nonnull (1,2))) + __MINGW_GNU_PRINTF(2, 0) __attribute__((nonnull (1,2))) int __cdecl __mingw_vasprintf(char ** __restrict__ , const char * __restrict__ , va_list) __MINGW_NOTHROW; extern - __attribute
[Mingw-w64-public] [PATCH 2/2] headers: Don't use the ms_printf/scanf and gnu_printf/scanf format attributes with clang
Clang doesn't support the ms_printf/scanf and gnu_printf/scanf format attributes, only plain "printf" and "scanf". We already expand e.g. __MINGW_PRINTF_FORMAT (which differs depending on __USE_MINGW_ANSI_STDIO) into plain "printf" for Clang, since 015e637b4b24d9915162ab877ed539ad0e657951. However, a number of functions explicitly declared either gnu or ms style formats, which caused these functions to not get any format string diagnostics. This fixes https://github.com/llvm/llvm-project/issues/68995, which reported that no warnings are produced for mismatched printf/scanf format strings, when compiling with Clang, with a toolchain targeting msvcrt (i.e. in practice using __USE_MINGW_ANSI_STDIO enabled). Signed-off-by: Martin Storsjö --- mingw-w64-headers/crt/_mingw_mac.h | 14 ++ 1 file changed, 14 insertions(+) diff --git a/mingw-w64-headers/crt/_mingw_mac.h b/mingw-w64-headers/crt/_mingw_mac.h index 9de143e5d..6c133d00e 100644 --- a/mingw-w64-headers/crt/_mingw_mac.h +++ b/mingw-w64-headers/crt/_mingw_mac.h @@ -267,6 +267,19 @@ # define __MINGW_ATTRIB_DEPRECATED_SEC_WARN #endif +#ifdef __clang__ +#define __MINGW_MS_PRINTF(__format,__args) \ + __attribute__((__format__(printf, __format,__args))) + +#define __MINGW_MS_SCANF(__format,__args) \ + __attribute__((__format__(scanf, __format,__args))) + +#define __MINGW_GNU_PRINTF(__format,__args) \ + __attribute__((__format__(printf,__format,__args))) + +#define __MINGW_GNU_SCANF(__format,__args) \ + __attribute__((__format__(scanf, __format,__args))) +#else #define __MINGW_MS_PRINTF(__format,__args) \ __attribute__((__format__(ms_printf, __format,__args))) @@ -278,6 +291,7 @@ #define __MINGW_GNU_SCANF(__format,__args) \ __attribute__((__format__(gnu_scanf, __format,__args))) +#endif /* !__clang__ */ #undef __mingw_ovr -- 2.34.1 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] headers: Use asm() for redirecting time functions, instead of inline functions
On Wed, 8 May 2024, Jacek Caban wrote: On 8.05.2024 14:22, Martin Storsjö wrote: Prior to 1652e9241b5d8a5a779c6582b1c3c4f4a7cc66e5, the inline functions always were static. Due to reexporting such symbols in C++20 modules (for the C++23 std module), the reexported symbols must not be static, so the inline functions were changed from static inline to __mingw_ovr, which practically is static inline in C mode, but regular inline in C++ mode. By using regular inline in C++ mode, each use of the functions can (but doesn't need to) emit an external symbol for the inline function, and the callers may either call that function or inline the body of the function. This can have two potential issues; if different translation units are configured differently (with the _USE_32BIT_TIME_T define), but both use the same external symbol for it, the linker will only keep one of them (as they're both inline, and supposed to be the same). In practice, this is rare for _USE_32BIT_TIME_T though. Secondly, such an external symbol may conflict with the actual import library. Such a case was reported at https://github.com/mstorsjo/llvm-mingw/issues/427. (Practically, the issue there was that some built object files defined an external "_time" symbol, i.e. regular "time" with i386 cdecl underscore prefix, from the non-static inline functions. The object also files reference _time32 with dllimport, which via the weak aliases produced by llvm-dlltool end up pulling in the __imp__time symbol, which also brings in a conflicting "_time" symbol.) In short - inline functions can be problematic. Where possible, it's less problematic to use asm(), via __MINGW_ASM_CALL(), to redirect calls directly towards the right function. This has a slight drawback, that this ends up calling the thunks (as the declarations lack dllimport), while we previously could inline the call directly to a dllimported function (avoiding the thunk, fetching the target address via the __imp_ prefixed symbol). We could, easily, add the dllimport attributes on these declarations, but that triggers a GCC bug for how those symbol names are mangled on i386, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114984. (The bug seems to be noted and mentioned as early as 2007, in https://sourceware.org/pipermail/cygwin/2007-February/154845.html, but it doesn't seem to have been fixed since.) Signed-off-by: Martin Storsjö --- mingw-w64-headers/crt/time.h | 62 1 file changed, 28 insertions(+), 34 deletions(-) Looks good to me. Thanks, pushed now. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH] headers: Use asm() for redirecting time functions, instead of inline functions
Prior to 1652e9241b5d8a5a779c6582b1c3c4f4a7cc66e5, the inline
functions always were static. Due to reexporting such symbols
in C++20 modules (for the C++23 std module), the reexported symbols
must not be static, so the inline functions were changed
from static inline to __mingw_ovr, which practically is static
inline in C mode, but regular inline in C++ mode.
By using regular inline in C++ mode, each use of the functions
can (but doesn't need to) emit an external symbol for the
inline function, and the callers may either call that function
or inline the body of the function.
This can have two potential issues; if different translation units
are configured differently (with the _USE_32BIT_TIME_T define),
but both use the same external symbol for it, the linker will only
keep one of them (as they're both inline, and supposed to be the
same). In practice, this is rare for _USE_32BIT_TIME_T though.
Secondly, such an external symbol may conflict with the actual
import library. Such a case was reported at
https://github.com/mstorsjo/llvm-mingw/issues/427.
(Practically, the issue there was that some built object files
defined an external "_time" symbol, i.e. regular "time" with i386
cdecl underscore prefix, from the non-static inline functions. The
object also files reference _time32 with dllimport, which via the
weak aliases produced by llvm-dlltool end up pulling in the
__imp__time symbol, which also brings in a conflicting "_time" symbol.)
In short - inline functions can be problematic. Where possible,
it's less problematic to use asm(), via __MINGW_ASM_CALL(), to
redirect calls directly towards the right function.
This has a slight drawback, that this ends up calling the thunks
(as the declarations lack dllimport), while we previously could
inline the call directly to a dllimported function (avoiding the
thunk, fetching the target address via the __imp_ prefixed symbol).
We could, easily, add the dllimport attributes on these declarations,
but that triggers a GCC bug for how those symbol names are mangled
on i386, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114984. (The
bug seems to be noted and mentioned as early as 2007, in
https://sourceware.org/pipermail/cygwin/2007-February/154845.html,
but it doesn't seem to have been fixed since.)
Signed-off-by: Martin Storsjö
---
mingw-w64-headers/crt/time.h | 62
1 file changed, 28 insertions(+), 34 deletions(-)
diff --git a/mingw-w64-headers/crt/time.h b/mingw-w64-headers/crt/time.h
index f8401903c..d94a9f619 100644
--- a/mingw-w64-headers/crt/time.h
+++ b/mingw-w64-headers/crt/time.h
@@ -213,26 +213,20 @@ extern "C" {
#if !defined (RC_INVOKED) && !defined (_INC_WTIME_INL)
#define _INC_WTIME_INL
- wchar_t *__cdecl _wctime(const time_t *) __MINGW_ATTRIB_DEPRECATED_SEC_WARN;
-#ifndef __CRT__NO_INLINE
#ifndef _USE_32BIT_TIME_T
- __CRT_INLINE wchar_t *__cdecl _wctime(const time_t *_Time) { return
_wctime64(_Time); }
+ wchar_t *__cdecl _wctime(const time_t *_Time)
__MINGW_ATTRIB_DEPRECATED_SEC_WARN __MINGW_ASM_CALL(_wctime64);
#else
- __CRT_INLINE wchar_t *__cdecl _wctime(const time_t *_Time) { return
_wctime32(_Time); }
+ wchar_t *__cdecl _wctime(const time_t *_Time)
__MINGW_ATTRIB_DEPRECATED_SEC_WARN __MINGW_ASM_CALL(_wctime32);
#endif
-#endif /* __CRT__NO_INLINE */
#endif
#if !defined (RC_INVOKED) && !defined (_INC_WTIME_S_INL)
#define _INC_WTIME_S_INL
- errno_t __cdecl _wctime_s(wchar_t *, size_t, const time_t *);
-#ifndef __CRT__NO_INLINE
#ifndef _USE_32BIT_TIME_T
- __CRT_INLINE errno_t __cdecl _wctime_s (wchar_t *_Buffer,size_t
_SizeInWords,const time_t *_Time) { return _wctime64_s
(_Buffer,_SizeInWords,_Time); }
+ errno_t __cdecl _wctime_s (wchar_t *_Buffer,size_t _SizeInWords,const time_t
*_Time) __MINGW_ASM_CALL(_wctime64_s);
#else
- __CRT_INLINE errno_t __cdecl _wctime_s (wchar_t *_Buffer,size_t
_SizeInWords,const time_t *_Time) { return _wctime32_s
(_Buffer,_SizeInWords,_Time); }
+ errno_t __cdecl _wctime_s (wchar_t *_Buffer,size_t _SizeInWords,const time_t
*_Time) __MINGW_ASM_CALL(_wctime32_s);
#endif
-#endif /* __CRT__NO_INLINE */
#endif
#define _WTIME_DEFINED
@@ -241,33 +235,33 @@ extern "C" {
#ifndef RC_INVOKED
#ifdef _USE_32BIT_TIME_T
-__mingw_ovr time_t __CRTDECL time(time_t *_Time) { return _time32(_Time); }
+time_t __CRTDECL time(time_t *_Time) __MINGW_ASM_CALL(_time32);
#ifdef _UCRT
-__mingw_ovr int __CRTDECL timespec_get(struct timespec* _Ts, int _Base) {
return _timespec32_get((struct _timespec32*)_Ts, _Base); }
-#endif
-__mingw_ovr double __CRTDECL difftime(time_t _Time1,time_t _Time2) { return
_difftime32(_Time1,_Time2); }
-__mingw_ovr struct tm *__CRTDECL localtime(const time_t *_Time) { return
_localtime32(_Time); }
-__mingw_ovr errno_t __CRTDECL localtime_s(struct tm *_Tm,const time_t *_Time)
{ return _localtime32_s(_Tm,_Time); }
-__mingw_ovr struct tm *__CRTDECL gmtime(const
[Mingw-w64-public] [PATCH v2 6/7] crt: UCRT: Change 32-bit mode time functions without suffix to use 32-bit time_t
From: Pali Rohár
CRT header files ensures that time symbols without 32/64 suffixes are not
emitted. And linker always sees time symbols with explicit 32 or 64 suffix
name.
When CRT header files are not included then 32-bit MSVC compiler + linker
treats symbols without "64" suffix name as functions which use 32-bit
time_t, even for UCRT builds.
Do the same in mingw-w64, change 32-bit mode time symbol aliases which do
not have "64" in symbol name, to point to symbols which use 32-bit time_t
type.
With this change, time symbols in 32-bit mode have same meaning across all
CRT libraries provided by mingw-w64. For example symbol "time" points to
function "time" function which always takes 32-bit time_t.
This change fixes previous commits 42aa3325fcfee934d7b706b701e49ee7a3c94982
and e37b315bc039a10507c5cb1046d6b891506022be
Signed-off-by: Martin Storsjö
---
mingw-w64-crt/Makefile.am | 8 ++--
.../api-ms-win-crt-filesystem-l1-1-0.def.in | 4 +-
def => api-ms-win-crt-time-l1-1-0.def.in} | 35 --
mingw-w64-crt/lib-common/ucrtbase.def.in | 37 ---
4 files changed, 54 insertions(+), 30 deletions(-)
rename mingw-w64-crt/lib-common/{api-ms-win-crt-time-l1-1-0.def =>
api-ms-win-crt-time-l1-1-0.def.in} (60%)
diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index 97ba61e7a..08f5055e9 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -1114,7 +1114,7 @@ processed_defs += lib32/crtdll.def lib32/msvcrt10.def
lib32/msvcrt20.def lib32/m
lib32/msvcr80.def lib32/msvcr90.def
lib32/msvcr90d.def lib32/msvcr100.def lib32/msvcr110.def lib32/msvcr120.def
lib32/msvcr120d.def \
lib32/msvcr120_app.def lib32/msvcp120_app.def
lib32/ucrtbase.def \
lib32/api-ms-win-crt-math-l1-1-0.def
lib32/api-ms-win-crt-private-l1-1-0.def lib32/api-ms-win-crt-runtime-l1-1-0.def
\
- lib32/api-ms-win-crt-filesystem-l1-1-0.def \
+ lib32/api-ms-win-crt-filesystem-l1-1-0.def
lib32/api-ms-win-crt-time-l1-1-0.def \
lib32/vcruntime140_app.def
endif
@@ -1491,7 +1491,7 @@ processed_defs += lib64/msvcrt.def lib64/msvcr80.def
lib64/msvcr90.def lib64/msv
lib64/advapi32.def lib64/clbcatq.def
lib64/kernel32.def lib64/ole32.def \
lib64/oleaut32.def lib64/user32.def
lib64/ws2_32.def \
lib64/api-ms-win-crt-math-l1-1-0.def
lib64/api-ms-win-crt-private-l1-1-0.def lib64/api-ms-win-crt-runtime-l1-1-0.def
\
- lib64/api-ms-win-crt-filesystem-l1-1-0.def \
+ lib64/api-ms-win-crt-filesystem-l1-1-0.def
lib64/api-ms-win-crt-time-l1-1-0.def \
lib64/vcruntime140_app.def
endif
@@ -1834,7 +1834,7 @@ processed_defs += libarm32/msvcrt.def
libarm32/msvcr80.def libarm32/msvcr90.def
libarm32/advapi32.def libarm32/clbcatq.def
libarm32/kernel32.def libarm32/ole32.def libarm32/oleaut32.def \
libarm32/user32.def libarm32/ws2_32.def \
libarm32/api-ms-win-crt-math-l1-1-0.def
libarm32/api-ms-win-crt-private-l1-1-0.def
libarm32/api-ms-win-crt-runtime-l1-1-0.def \
- libarm32/api-ms-win-crt-filesystem-l1-1-0.def
\
+ libarm32/api-ms-win-crt-filesystem-l1-1-0.def
libarm32/api-ms-win-crt-time-l1-1-0.def \
libarm32/vcruntime140_app.def
endif
@@ -2129,7 +2129,7 @@ processed_defs += libarm64/msvcrt.def
libarm64/ucrtbase.def \
libarm64/advapi32.def libarm64/clbcatq.def
libarm64/kernel32.def libarm64/ole32.def libarm64/oleaut32.def \
libarm64/user32.def libarm64/ws2_32.def \
libarm64/api-ms-win-crt-math-l1-1-0.def
libarm64/api-ms-win-crt-private-l1-1-0.def
libarm64/api-ms-win-crt-runtime-l1-1-0.def \
- libarm64/api-ms-win-crt-filesystem-l1-1-0.def
\
+ libarm64/api-ms-win-crt-filesystem-l1-1-0.def
libarm64/api-ms-win-crt-time-l1-1-0.def \
libarm64/vcruntime140_app.def
endif
diff --git a/mingw-w64-crt/lib-common/api-ms-win-crt-filesystem-l1-1-0.def.in
b/mingw-w64-crt/lib-common/api-ms-win-crt-filesystem-l1-1-0.def.in
index 219361b70..d676251b4 100644
--- a/mingw-w64-crt/lib-common/api-ms-win-crt-filesystem-l1-1-0.def.in
+++ b/mingw-w64-crt/lib-common/api-ms-win-crt-filesystem-l1-1-0.def.in
@@ -14,13 +14,13 @@ _chdrive
_chmod
chmod == _chmod
_findclose
-F32(_findfirst == _findfirst64)
+F32(_findfirst == _findfirst32)
F6
[Mingw-w64-public] [PATCH v2 1/7] crt: msvcr90d.def.in: Fix X64 ctime symbol alias to use 64-bit time_t
From: Pali Rohár Signed-off-by: Martin Storsjö --- mingw-w64-crt/lib64/msvcr90d.def.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mingw-w64-crt/lib64/msvcr90d.def.in b/mingw-w64-crt/lib64/msvcr90d.def.in index 3c7d7525a..f8f6ecae1 100644 --- a/mingw-w64-crt/lib64/msvcr90d.def.in +++ b/mingw-w64-crt/lib64/msvcr90d.def.in @@ -418,7 +418,7 @@ _cscanf_l _cscanf_s _cscanf_s_l _ctime32 -ctime == _ctime32 +ctime == _ctime64 _ctime32_s _ctime64 _ctime64_s -- 2.34.1 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH v2 4/7] crt: msvcr120_app.def.in: Fix X64 symbol aliases _stat and _stati64
From: Pali Rohár Symbol alias is defined by "==". Signed-off-by: Martin Storsjö --- mingw-w64-crt/lib-common/msvcr120_app.def.in | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/mingw-w64-crt/lib-common/msvcr120_app.def.in b/mingw-w64-crt/lib-common/msvcr120_app.def.in index e2474e77c..8319ed012 100644 --- a/mingw-w64-crt/lib-common/msvcr120_app.def.in +++ b/mingw-w64-crt/lib-common/msvcr120_app.def.in @@ -1669,8 +1669,8 @@ _stat64 F_X86_ANY(_stat64i32) F_I386(_stat == _stat32) F_I386(_stati64 == _stat32i64) -F_X64(_stat = _stat64i32) -F_X64(_stati64 = _stat64) +F_X64(_stat == _stat64i32) +F_X64(_stati64 == _stat64) F_ARM32(_stati64) _statusfp F_I386(_statusfp2) -- 2.34.1 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH v2 7/7] crt: Move find, stat and time aliases to def-include/msvcrt-common.def.in
From: Pali Rohár Add 4 new macros FIXED_SIZE_SYMBOLS, NO_I64_FIXED_SIZE, NO_FIXED_SIZE_64_ALIAS and NO_TIME_ALIAS to distinguish between different crt versions. This change adds new symbol aliases which were missing. There is no symbol change or removal. For reference here is list of changes between individual outputs from: cpp -x c $FILE -Wp,-w -undef -P -Imingw-w64-crt/def-include -D$PLAT | sed -E 's/\s*;.*//' | LC_ALL=C sort -u Signed-off-by: Martin Storsjö --- .../def-include/msvcrt-common.def.in | 157 ++ mingw-w64-crt/lib-common/msvcr120_app.def.in | 33 +--- mingw-w64-crt/lib-common/msvcrt.def.in| 23 +-- mingw-w64-crt/lib-common/ucrtbase.def.in | 24 --- mingw-w64-crt/lib32/crtdll.def.in | 12 +- mingw-w64-crt/lib32/msvcr100.def.in | 18 -- mingw-w64-crt/lib32/msvcr110.def.in | 18 -- mingw-w64-crt/lib32/msvcr120.def.in | 14 -- mingw-w64-crt/lib32/msvcr120d.def.in | 14 -- mingw-w64-crt/lib32/msvcr70.def.in| 12 +- mingw-w64-crt/lib32/msvcr71.def.in| 12 +- mingw-w64-crt/lib32/msvcr80.def.in| 22 --- mingw-w64-crt/lib32/msvcr90.def.in| 18 -- mingw-w64-crt/lib32/msvcr90d.def.in | 18 -- mingw-w64-crt/lib32/msvcrt10.def.in | 12 +- mingw-w64-crt/lib32/msvcrt20.def.in | 13 +- mingw-w64-crt/lib32/msvcrt40.def.in | 12 +- mingw-w64-crt/lib64/msvcr100.def.in | 18 -- mingw-w64-crt/lib64/msvcr110.def.in | 18 -- mingw-w64-crt/lib64/msvcr120.def.in | 14 -- mingw-w64-crt/lib64/msvcr120d.def.in | 13 -- mingw-w64-crt/lib64/msvcr80.def.in| 22 --- mingw-w64-crt/lib64/msvcr90.def.in| 18 -- mingw-w64-crt/lib64/msvcr90d.def.in | 18 -- 24 files changed, 172 insertions(+), 381 deletions(-) diff --git a/mingw-w64-crt/def-include/msvcrt-common.def.in b/mingw-w64-crt/def-include/msvcrt-common.def.in index 3e2c674d3..26aa13e6b 100644 --- a/mingw-w64-crt/def-include/msvcrt-common.def.in +++ b/mingw-w64-crt/def-include/msvcrt-common.def.in @@ -119,6 +119,9 @@ ADD_UNDERSCORE(ungetch) ADD_UNDERSCORE(unlink) #ifndef UCRTBASE ADD_UNDERSCORE(utime) +#else +F32(utime == _utime32) +F64(utime == _utime64) #endif ADD_UNDERSCORE(wcsdup) ADD_UNDERSCORE(wcsicmp) @@ -197,6 +200,160 @@ _strtoimax_l == _strtoi64_l _strtoumax_l == _strtoui64_l #endif +; This is list of find symbol aliases, every CRT library has either find symbols with SIZE suffix or without them +#ifdef FIXED_SIZE_SYMBOLS +F32(_findfirst32 == _findfirst) +F64(_findfirst64i32 == _findfirst) +#ifndef NO_I64_FIXED_SIZE +F32(_findfirst32i64 == _findfirsti64) +#ifndef NO_FIXED_SIZE_64_ALIAS +F64(_findfirst64 == _findfirsti64) +#endif +#endif +F32(_findnext32 == _findnext) +F64(_findnext64i32 == _findnext) +#ifndef NO_I64_FIXED_SIZE +F32(_findnext32i64 == _findnexti64) +#ifndef NO_FIXED_SIZE_64_ALIAS +F64(_findnext64 == _findnexti64) +#endif +#endif +#ifndef NO_WIDE_FIXED_SIZE +F32(_wfindfirst32 == _wfindfirst) +F64(_wfindfirst64i32 == _wfindfirst) +#ifndef NO_I64_FIXED_SIZE +F32(_wfindfirst32i64 == _wfindfirsti64) +#ifndef NO_FIXED_SIZE_64_ALIAS +F64(_wfindfirst64 == _wfindfirsti64) +#endif +#endif +F32(_wfindnext32 == _wfindnext) +F64(_wfindnext64i32 == _wfindnext) +#ifndef NO_I64_FIXED_SIZE +F32(_wfindnext32i64 == _wfindnexti64) +#ifndef NO_FIXED_SIZE_64_ALIAS +F64(_wfindnext64 == _wfindnexti64) +#endif +#endif +#endif +#else +F32(_findfirst == _findfirst32) +F64(_findfirst == _findfirst64i32) +F32(_findfirsti64 == _findfirst32i64) +F64(_findfirsti64 == _findfirst64) +F32(_findnext == _findnext32) +F64(_findnext == _findnext64i32) +F32(_findnexti64 == _findnext32i64) +F64(_findnexti64 == _findnext64) +F32(_wfindfirst == _wfindfirst32) +F64(_wfindfirst == _wfindfirst64i32) +F32(_wfindfirsti64 == _wfindfirst32i64) +F64(_wfindfirsti64 == _wfindfirst64) +F32(_wfindnext == _wfindnext32) +F64(_wfindnext == _wfindnext64i32) +F32(_wfindnexti64 == _wfindnext32i64) +F64(_wfindnexti64 == _wfindnext64) +#endif + +; This is list of stat symbol aliases, every CRT library has either stat symbols with SIZE suffix or without them +#ifdef FIXED_SIZE_SYMBOLS +F32(_fstat32 == _fstat) +F64(_fstat64i32 == _fstat) +#ifndef NO_I64_FIXED_SIZE +F32(_fstat32i64 == _fstati64) +#ifndef NO_FIXED_SIZE_64_ALIAS +F64(_fstat64 == _fstati64) +#endif +#endif +F32(_stat32 == _stat) +F64(_stat64i32 == _stat) +#ifndef NO_I64_FIXED_SIZE +F32(_stat32i64 == _stati64) +#ifndef NO_FIXED_SIZE_64_ALIAS +F64(_stat64 == _stati64) +#endif +#endif +#ifndef NO_WIDE_FIXED_SIZE +F32(_wstat32 == _wstat) +F64(_wstat64i32 == _wstat) +#ifndef NO_I64_FIXED_SIZE +F32(_wstat32i64 == _wstati64) +#ifndef NO_FIXED_SIZE_64_ALIAS +F64(_wstat64 == _wstati64) +#endif +#endif +#endif +#else +F32(_fstat == _fstat32) +F64(_fstat == _fstat64i32) +F32(_fstati64 == _fstat32i64) +F64(_fstati64 == _fstat64) +F32(_stat == _stat32) +F64(_stat
[Mingw-w64-public] [PATCH v2 5/7] crt: msvcr120_app.def.in: Remove duplicate symbol alias swab
From: Pali Rohár This alias is already provided by the msvcrt-common.def.in file. Signed-off-by: Martin Storsjö --- mingw-w64-crt/lib-common/msvcr120_app.def.in | 1 - 1 file changed, 1 deletion(-) diff --git a/mingw-w64-crt/lib-common/msvcr120_app.def.in b/mingw-w64-crt/lib-common/msvcr120_app.def.in index 8319ed012..7fa9d0a32 100644 --- a/mingw-w64-crt/lib-common/msvcr120_app.def.in +++ b/mingw-w64-crt/lib-common/msvcr120_app.def.in @@ -1723,7 +1723,6 @@ _strupr_s _strupr_s_l _strxfrm_l _swab -F_I386(swab == _swab) _swprintf _swprintf_c _swprintf_c_l -- 2.34.1 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH v2 2/7] crt: msvcr90d.def.in: Fix I386 symbol alias _wfindnext
From: Pali Rohár Symbol redirects in import libraries are defined by "==", while "=" in def files is used to rename a symbol on export, while linking a DLL (but that does not have any effect when creating an import library with dlltool). Signed-off-by: Martin Storsjö --- mingw-w64-crt/lib32/msvcr90d.def.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mingw-w64-crt/lib32/msvcr90d.def.in b/mingw-w64-crt/lib32/msvcr90d.def.in index 4c31b6323..db2eb6e01 100644 --- a/mingw-w64-crt/lib32/msvcr90d.def.in +++ b/mingw-w64-crt/lib32/msvcr90d.def.in @@ -1295,7 +1295,7 @@ _wfindfirst32i64 _wfindfirst64 _wfindfirst64i32 _wfindnext32 -_wfindnext = _wfindnext32 +_wfindnext == _wfindnext32 _wfindnext32i64 _wfindnext64 _wfindnext64i32 -- 2.34.1 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH v2 3/7] crt: msvcr120 and UCRT: Fix 64 bit _(w)findfirst and _(w)findnext symbol aliases
From: Pali Rohár
These symbols on 64 bit should resolve to _findfirst64i32/_findnext64i32
functions, like in other CRT libraries and header files.
The UCRT 32 bit aliases are kept as they were before (even if
they are known to be incorrect); they are corrected in a separate
later commit.
Signed-off-by: Martin Storsjö
---
mingw-w64-crt/Makefile.am | 4
...l1-1-0.def => api-ms-win-crt-filesystem-l1-1-0.def.in} | 8 ++--
mingw-w64-crt/lib-common/msvcr120_app.def.in | 8
mingw-w64-crt/lib-common/ucrtbase.def.in | 6 --
mingw-w64-crt/lib64/msvcr120.def.in | 4 ++--
mingw-w64-crt/lib64/msvcr120d.def.in | 4 ++--
6 files changed, 22 insertions(+), 12 deletions(-)
rename mingw-w64-crt/lib-common/{api-ms-win-crt-filesystem-l1-1-0.def =>
api-ms-win-crt-filesystem-l1-1-0.def.in} (85%)
diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index e6a21446b..97ba61e7a 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -1114,6 +1114,7 @@ processed_defs += lib32/crtdll.def lib32/msvcrt10.def
lib32/msvcrt20.def lib32/m
lib32/msvcr80.def lib32/msvcr90.def
lib32/msvcr90d.def lib32/msvcr100.def lib32/msvcr110.def lib32/msvcr120.def
lib32/msvcr120d.def \
lib32/msvcr120_app.def lib32/msvcp120_app.def
lib32/ucrtbase.def \
lib32/api-ms-win-crt-math-l1-1-0.def
lib32/api-ms-win-crt-private-l1-1-0.def lib32/api-ms-win-crt-runtime-l1-1-0.def
\
+ lib32/api-ms-win-crt-filesystem-l1-1-0.def \
lib32/vcruntime140_app.def
endif
@@ -1490,6 +1491,7 @@ processed_defs += lib64/msvcrt.def lib64/msvcr80.def
lib64/msvcr90.def lib64/msv
lib64/advapi32.def lib64/clbcatq.def
lib64/kernel32.def lib64/ole32.def \
lib64/oleaut32.def lib64/user32.def
lib64/ws2_32.def \
lib64/api-ms-win-crt-math-l1-1-0.def
lib64/api-ms-win-crt-private-l1-1-0.def lib64/api-ms-win-crt-runtime-l1-1-0.def
\
+ lib64/api-ms-win-crt-filesystem-l1-1-0.def \
lib64/vcruntime140_app.def
endif
@@ -1832,6 +1834,7 @@ processed_defs += libarm32/msvcrt.def
libarm32/msvcr80.def libarm32/msvcr90.def
libarm32/advapi32.def libarm32/clbcatq.def
libarm32/kernel32.def libarm32/ole32.def libarm32/oleaut32.def \
libarm32/user32.def libarm32/ws2_32.def \
libarm32/api-ms-win-crt-math-l1-1-0.def
libarm32/api-ms-win-crt-private-l1-1-0.def
libarm32/api-ms-win-crt-runtime-l1-1-0.def \
+ libarm32/api-ms-win-crt-filesystem-l1-1-0.def
\
libarm32/vcruntime140_app.def
endif
@@ -2126,6 +2129,7 @@ processed_defs += libarm64/msvcrt.def
libarm64/ucrtbase.def \
libarm64/advapi32.def libarm64/clbcatq.def
libarm64/kernel32.def libarm64/ole32.def libarm64/oleaut32.def \
libarm64/user32.def libarm64/ws2_32.def \
libarm64/api-ms-win-crt-math-l1-1-0.def
libarm64/api-ms-win-crt-private-l1-1-0.def
libarm64/api-ms-win-crt-runtime-l1-1-0.def \
+ libarm64/api-ms-win-crt-filesystem-l1-1-0.def
\
libarm64/vcruntime140_app.def
endif
diff --git a/mingw-w64-crt/lib-common/api-ms-win-crt-filesystem-l1-1-0.def
b/mingw-w64-crt/lib-common/api-ms-win-crt-filesystem-l1-1-0.def.in
similarity index 85%
rename from mingw-w64-crt/lib-common/api-ms-win-crt-filesystem-l1-1-0.def
rename to mingw-w64-crt/lib-common/api-ms-win-crt-filesystem-l1-1-0.def.in
index 45ae728ba..219361b70 100644
--- a/mingw-w64-crt/lib-common/api-ms-win-crt-filesystem-l1-1-0.def
+++ b/mingw-w64-crt/lib-common/api-ms-win-crt-filesystem-l1-1-0.def.in
@@ -2,6 +2,8 @@ LIBRARY api-ms-win-crt-filesystem-l1-1-0
EXPORTS
+#include "func.def.in"
+
_access
; access is provided as an alias for __mingw_access
; access == _access
@@ -12,12 +14,14 @@ _chdrive
_chmod
chmod == _chmod
_findclose
-_findfirst == _findfirst64
+F32(_findfirst == _findfirst64)
+F64(_findfirst == _findfirst64i32)
_findfirst32
_findfirst32i64
_findfirst64
_findfirst64i32
-_findnext == _findnext64
+F32(_findnext == _findnext64)
+F64(_findnext == _findnext64i32)
_findnext32
_findnext32i64
_findnext64
diff --git a/mingw-w64-crt/lib-common/msvcr120_app.def.in
b/mingw-w64-crt/lib-common/msvcr120_app.def.in
index 1cc754856..e2474e77c 100644
--- a/mingw-w64-crt/lib-common/msvcr120_app.def.in
+++ b/mingw-w64-crt/lib-common/msvcr120_app.def.in
@@ -,7 +,7 @@ F_I386(_findfirst == _findfirst32)
F_X86_ANY
Re: [Mingw-w64-public] [PATCH 2/7] crt: msvcr90d.def.in: Fix I386 symbol alias _wfindnext
On Sat, 27 Apr 2024, LIU Hao wrote: 在 2024-04-27 19:46, Pali Rohár 写道: Symbol alias is defined by "==". This message is incorrect. `=` really defines an alias [1]. `==` specifies the export name (the name before `==` is used by the linker). For an import library, there is likely no difference. The difference arises when building a DLL with this DEF file: * `foo = bar` (aliasing) indicates that a function called `bar` exists in the DLL's source code, and it is exported both as `foo` and `bar`. No, if this is used when linking a DLL, it does not export both names, it only exports "foo". I don't mind the casual use of "alias" for these purposes for how we normally use it - but I agree that saying "==" defines an alias, is incorrect. Anyway, I tried to clarify this bit in the commit messages (and fix a few other bits); I'll re-send the whole set of patches to the list before pushing. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 7/7] crt: Move find, stat and time aliases to def-include/msvcrt-common.def.in
On Sat, 27 Apr 2024, Pali Rohár wrote: Add 4 new macros FIXED_SIZE_SYMBOLS, NO_I64_FIXED_SIZE, NO_FIXED_SIZE_64_ALIAS and NO_TIME_ALIAS to distinguish between different crt versions. This change adds new symbol aliases which were missing. There is no symbol change or removal. For reference here is list of changes between individual outputs from: cpp -x c $FILE -Wp,-w -undef -P -Imingw-w64-crt/def-include -D$PLAT | sed -E 's/\s*;.*//' | LC_ALL=C sort -u diff --git a/mingw-w64-crt/def-include/msvcrt-common.def.in b/mingw-w64-crt/def-include/msvcrt-common.def.in index 3e2c674d3699..26aa13e6b661 100644 --- a/mingw-w64-crt/def-include/msvcrt-common.def.in +++ b/mingw-w64-crt/def-include/msvcrt-common.def.in @@ -119,6 +119,9 @@ ADD_UNDERSCORE(ungetch) ADD_UNDERSCORE(unlink) #ifndef UCRTBASE ADD_UNDERSCORE(utime) +#else +F32(utime == _utime32) +F64(utime == _utime64) #endif ADD_UNDERSCORE(wcsdup) ADD_UNDERSCORE(wcsicmp) @@ -197,6 +200,160 @@ _strtoimax_l == _strtoi64_l _strtoumax_l == _strtoui64_l #endif +; This is list of find symbol aliases, every CRT library has either find symbols with SIZE suffix or without them +#ifdef FIXED_SIZE_SYMBOLS +F32(_findfirst32 == _findfirst) +F64(_findfirst64i32 == _findfirst) +#ifndef NO_I64_FIXED_SIZE +F32(_findfirst32i64 == _findfirsti64) +#ifndef NO_FIXED_SIZE_64_ALIAS +F64(_findfirst64 == _findfirsti64) I think this patch looks reasonable; the diff of the def files looks good. I didn't try to follow this macro soup in detail, but I guess it's reasonable as long as the output is correct. Overall, I'm ok with this patch set now, thanks! (I just had a few minor nits about the commit messages.) I'll leave the naming discussion regarding "alias"/redirect to Liu Hao. (Also, note the name "alias" exists in multiple commit messages, and also in macros in this patch.) I'll be away for the rest of the week, so unless someone else wants to apply it once the naming discussion has been settled, I can probably get to it sometime next week. (Also, if someone else wants to apply it, note that there are changes to Makefile.am that need regenerating Makefile.in after each change.) // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 3/7] crt: msvcr120 and UCRT: Fix X64 _(w)findfirst and _(w)findnext symbol aliases
On Sat, 27 Apr 2024, Pali Rohár wrote: These symbols on X64 should resolve to _findfirst64i32/_findnext64i32 functions, like in other CRT libraries and header files. It could be worth mentioning in the commit message, that the 32 bit versions of these aliases or redirects, are intentionally left as they were, even if we at this point know its wrong, as we are about to change it in a later patch soon. (Leaving things untouched is one thing, but here we're adding new F32() wrappers, even if they are kept pointing at the wrong function.) // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 6/7] crt: UCRT: Change I386 time functions without suffix to use 32-bit time_t
On Sat, 27 Apr 2024, Pali Rohár wrote: CRT header files ensures that time symbols without 32/64 suffixes are not emitted. And linker always sees time symbols with explicit 32 or 64 suffix name. When CRT header files are not included then 32-bit MSVC compiler + linker treats symbols without "64" suffix name as functions which use 32-bit time_t, even for UCRT builds. Do some in mingw-w64, change I386 time symbol aliases which do not have "64" in symbol name, to point to symbols which use 32-bit time_t type. Typo in this sentence, I presume you mean "Do the same" or something like that? Another nitpick for the commit messages in this whole series; the commit messages talk about I386 and X64, while it actually is generic for 32 and 64 bit, as we do support armv7 and aarch64 too. So in order to avoid confusion, especially as there actually are lots of cases that are i386 specific too, but not these, it would be good to refer more generically to this as 32/64 bit in these commit messages. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 2/7] crt: msvcr90d.def.in: Fix I386 symbol alias _wfindnext
On Tue, 30 Apr 2024, Martin Storsjö wrote:
On Mon, 29 Apr 2024, Pali Rohár wrote:
So based on these experiments when building library, I can conclude
that:
X = Y
is the same as:
Y == X
and it means that function named X in the source code is present in the
result DLL library under name Y.
So `foo = bar` is also renaming of the symbol, and not aliasing.
For completeness, what happens when both = and == are used at the same
line:
$ cat test.def
LIBRARY "test.dll"
EXPORTS
foo = func == bar
$ cat test.c
void func(void) { }
$ i686-w64-mingw32-gcc -shared test.c test.def -o test.dll
$ readpe -e test.dll
Exported functions
Library
Name:test.dll
Functions
Function
Ordinal: 1
Address: 0x1410
Name:bar
So line "X = Y == Z" has same meaning as "Y == Z" and so same as "Z =
X".
Such logic does not make sense for me, but whatever. It shows that
documentation is incomplete and ambiguous.
As far as I know, they're used in different circumstances. When linking a
DLL, you'd use the syntax "X = Y" to export a symbol under a different
name. MS link also supports this syntax for this purpose.
When creating an import library with dlltool, the == syntax is used with
the purpose of creating an import library with a symbol with one name,
pointing at a DLL export with a different name.
I see you only inspected the export table of the linked DLLs in your
experiment, but you also should create an import library at the same time
(-Wl,--out-implib) and inspect what symbols it provides - which hopefully
would link against the export names of the DLL that was created at the
same time.
It's probably also interesting to test and see what dlltool does with this
kind of def file.
// Martin
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 2/7] crt: msvcr90d.def.in: Fix I386 symbol alias _wfindnext
On Mon, 29 Apr 2024, Pali Rohár wrote:
So based on these experiments when building library, I can conclude that:
X = Y
is the same as:
Y == X
and it means that function named X in the source code is present in the
result DLL library under name Y.
So `foo = bar` is also renaming of the symbol, and not aliasing.
For completeness, what happens when both = and == are used at the same line:
$ cat test.def
LIBRARY "test.dll"
EXPORTS
foo = func == bar
$ cat test.c
void func(void) { }
$ i686-w64-mingw32-gcc -shared test.c test.def -o test.dll
$ readpe -e test.dll
Exported functions
Library
Name:test.dll
Functions
Function
Ordinal: 1
Address: 0x1410
Name:bar
So line "X = Y == Z" has same meaning as "Y == Z" and so same as "Z = X".
Such logic does not make sense for me, but whatever. It shows that
documentation is incomplete and ambiguous.
As far as I know, they're used in different circumstances. When linking a
DLL, you'd use the syntax "X = Y" to export a symbol under a different
name. MS link also supports this syntax for this purpose.
When creating an import library with dlltool, the == syntax is used with
the purpose of creating an import library with a symbol with one name,
pointing at a DLL export with a different name.
I see you only inspected the export table of the linked DLLs in your
experiment, but you also should create an import library at the same time
(-Wl,--out-implib) and inspect what symbols it provides - which hopefully
would link against the export names of the DLL that was created at the
same time.
// Martin
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 10/10] crt: Move find, stat and time aliases to def-include/msvcrt-common.def.in
On Sat, 27 Apr 2024, Jacek Caban wrote: On 26.04.2024 21:43, Pali Rohár wrote: I played a bit with different msvc 19.x versions and 32-bit x86 variant recognize time symbol and maps it to _time32 at link time. First compiler maps time symbol to _time and then linker maps _time to __time32. It means that msvc import libraries have symbol "time" as alias to "_time32" function. It can be easily played with it on godbolt: https://godbolt.org/z/PT6WzEoaP After adding #include for proper time() declaration, msvc translated at compile time it to _time64 symbol. And linker resolved _time64 to __time64. https://godbolt.org/z/1YY557ePK So this shows that msvc "time" symbol in x86 32-bit object files uses 32-bit time_t type. It means that 64-bit time_t type is enforced by the compiler which emits _time64 symbol. Good point, that's not what I expected. Changing that seems fine to me then (as Martin said, separated from refactoring). I guess this can be considered reasonable too. In the commit that changes this, mention that this changes the earlier way how these symbols are interpreted, from e37b315bc039a10507c5cb1046d6b891506022be and 42aa3325fcfee934d7b706b701e49ee7a3c94982. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 10/10] crt: Move find, stat and time aliases to def-include/msvcrt-common.def.in
On Fri, 26 Apr 2024, Jacek Caban wrote:
On 25.04.2024 23:11, Pali Rohár wrote:
And also it would allow to create object file which
calls "_findfirst" symbol and then link it with any mingw-w64 CRT import
library.
Mixing crts is problematic for many reasons, this is just one of them. And if
one really needs to go that far, it's better to just use *32 or *64 variant
explicitly, which would entirely avoid the confusion and should be possible
with current crt.
I think it is better to have stable symbol meaning than to have symbol
alias matching what the headers default to. Stable symbol meaning can be
an invariant in this case. But symbol matching with header file is not
stable as application can change it by -D_USE_32BIT_TIME_T.
What do you think? Does it make sense?
Sure, an application can change it on per-file basis, but it's way more
likely that it doesn't and just uses the default. If we provide a different
default behavior in headers, why wouldn't we reflect that in crt part?
FWIW, I just dug up the history of these aliases, and this has clearly
been the intent so far (even if the exact symbol it references isn't
entirely right wrt _findfirst at least) - see the following commits:
commit a648ec2af9aa731a264ad00223940f5cd67ca285
Author: Martin Storsjö
Date: Sun Nov 12 22:41:31 2017 +0200
crt: Map _find{first,next} to _find{first,next}32 on ucrtbase
commit 42aa3325fcfee934d7b706b701e49ee7a3c94982
Author: Liu Hao
Date: Tue Mar 30 22:19:33 2021 +0800
crt: Add symbols for POSIX time functions and find{first,next} functions
commit e37b315bc039a10507c5cb1046d6b891506022be
Author: Liu Hao
Date: Mon Apr 5 18:18:54 2021 +0800
include/_mingw.h.in,crt: Extend `time_t` to 64 bits for UCRT for 32-bit
targets
// Martin
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 5/5] headers: Stop using the __mingw_static_ovr macro
On Thu, 25 Apr 2024, Jacek Caban wrote: Patches look good to me. Thanks! I'll go ahead and push them then. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 00/10] crt: Move symbol aliases from CRT def files to msvcrt-common.def.in
On Thu, 25 Apr 2024, Pali Rohár wrote: On Thursday 25 April 2024 20:18:44 Pali Rohár wrote: On Wednesday 24 April 2024 23:34:50 Martin Storsjö wrote: On Mon, 22 Apr 2024, Pali Rohár wrote: This patch series moves all aliases defined in crtdll.def.in, and msvcr*.def.in files into one common include file msvcrt-common.def.in. It reduces duplication of symbol alias definitions by defining symbols in more declarative manner. Moving aliases to one place uncovered that some def.in files were missing some alises (mostly for __ms_* printf/scanf symbols) or some were incorrectly defined (ctime for 64-bit msvcr90d.def.in was defined as alias to _ctime32 instead of _ctime64, or _findfirst for 64-bit msvcr120.def.in was defined as alias to symbol which does _not_ use 32-bit file length). For reference what this change affects, I'm attaching a difference which was generated for each CRT def.in file by command ($PLAT: DEF_I386 DEF_X64): cpp -x c -Wp,-w -undef -P -Imingw-w64-crt/def-include -D$PLAT | sed -E 's/\s*;.*//' | LC_ALL=C sort -u I presume you didn't diff the changes for ucrtbase.def.in? Because it seems to be changes that do affect the output from that one, in patch 10/10. Ou, I completely forgot to look at ucrtbase difference. Too many CRT libs. For reference here is the difference before and after 10/10 patch. I will inspect it and let know about issues. --- lib32/ucrtbase.def.in +++ lib32/ucrtbase.def.in -_findfirst == _findfirst64 +_findfirst == _findfirst32 -_findnext == _findnext64 +_findnext == _findnext32 +_findfirsti64 == _findfirst32i64 +_findnexti64 == _findnext32i64 +_fstat == _fstat32 +_fstati64 == _fstat32i64 -_ftime == _ftime64 +_ftime == _ftime32 -_futime == _futime64 +_futime == _futime32 +_mkgmtime == _mkgmtime32 +_stat == _stat32 +_stati64 == _stat32i64 -_utime == _utime64 +_utime == _utime32 +_wctime == _wctime32 +_wfindfirst == _wfindfirst32 +_wfindfirsti64 == _wfindfirst32i64 +_wfindnext == _wfindnext32 +_wfindnexti64 == _wfindnext32i64 +_wstat == _wstat32 +_wstati64 == _wstat32i64 -_wutime == _wutime64 +_wutime == _wutime32 -ctime == _ctime64 +ctime == _ctime32 +difftime == _difftime32 -gmtime == _gmtime64 +gmtime == _gmtime32 -localtime == _localtime64 +localtime == _localtime32 -mktime == _mktime64 +mktime == _mktime32 -time == _time64 +time == _time32 -utime == _utime64 --- lib64/ucrtbase.def.in +++ lib64/ucrtbase.def.in -_findfirst == _findfirst64 +_findfirst == _findfirst64i32 On 64-bit is mingw-w64's io.h using: #define _findfirst _findfirst64i32 And seem that this also matches 64-bit msvcrt.dll. So I think that current ucrtbase.def.in has wrongly defined _findfirst symbol (and also _findnext). And my change is fixing it. Yes, it's probably fixing it - but it should be in a different patch. And the change for lib32/ucrtbase.def.in, making it point at _findfirst32 is wrong IMO, it should also point at _findfirst64i32. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 10/10] crt: Move find, stat and time aliases to def-include/msvcrt-common.def.in
On Thu, 25 Apr 2024, Pali Rohár wrote: On Wednesday 24 April 2024 23:41:24 Martin Storsjö wrote: On Mon, 22 Apr 2024, Pali Rohár wrote: diff --git a/mingw-w64-crt/lib-common/ucrtbase.def.in b/mingw-w64-crt/lib-common/ucrtbase.def.in index 2d0552f277ef..c8fb1e33b1d7 100644 --- a/mingw-w64-crt/lib-common/ucrtbase.def.in +++ b/mingw-w64-crt/lib-common/ucrtbase.def.in @@ -327,12 +327,10 @@ _filelength _filelengthi64 _fileno _findclose -_findfirst == _findfirst64 Note how we unconditionally had these macros pointing at _findfirst64 in ucrt, regardless of architecture. I must admit that this is an interesting issue. I looked at the mingw-w64-headers/crt/io.h file now and it is not set unconditionally as you wrote. I didn't say that the headers unconditionally uses it this way. I just said that the exist, most probably buggy, def file line right above what I quoted, unconditionally does "_findfirst == _findfirst64" for all architectures. Yes it's probably wrong - but we shouldn't be changing it in a refactoring patch, that's all I tried to say here. Anyway, this def file defines symbol alias "_findfirst" for linking. And every c/c++ source file which includes headers files would result in object file which will use either "_findfirst32" or "_findfirst64i32". Not "_findfirst" symbol. So in my opinion, this change should be safe. It may very well be safe in practice, but I don't want such a subtle, unannounced change buried in a patch that refactors many hundreds of lines, where the rest mostly is a pure refactoring. I think that meaning of the symbols should be same independently of the used CRT library. And for me this looks like a bug that UCRT was resolving _findfirst to different ABI function than msvcrt, at link time. I disagree here. UCRT has a different ABI than msvcrt, overall, with time_t defaulting to 64 bit on UCRT on 32 bit platforms, contrary to msvcrt. I think the default symbol here should match what the headers default to, when used in a UCRT configuration. I guess that it was rare to hit this issue as it required to either not include mingw-w64 header files and declare functions manually. Or write application in other language which does not use mingw-w64 C header files (e.g. in assembly or something similar) but uses mingw-w64 CRT libraries for linking. Yes, this is not something that would be encountered often in practice, I agree with that. Please check what I wrote above. If you agree that this is a bug, I can prepare a separate fix for the UCRT (and then rebase 10/10 on top of it). I agree that the current state probably is a bug. As the headers default to 64 bit time_t, then _findfirst should probably resolve to _findfirst64i32, for both 32 and 64 bit. Similarly for the other symbols. That's most probably my original intent in how I set these up - that we point at the "64 bit version", but I missed that it really is _findfirst64i32 and not _findfirst64. I'd appreciate a patch that fixes these aliases, consistently for ucrtbase.def.in and the api-ms-win-crt-*.def.in, and then we can rebase patch 10/10 on top of it, where I'd expect no changes in the preprocessed output of the ucrt def files. Ou, and another files for which I forget api-ms-win-crt-*.def.in. And this is because they do not include that common .def.in file. I can look at them, but I would prefer to do it after all existing stuff is resolved as basically api-ms-win-crt-*.def.in does not use any common aliases. In my opinion, it would be better to change *crt*.def.in and api-ms-win-crt-*.def.in files to use common alias (would need refactor). Yes, that would indeed require a bit of refactoring. I'm not requesting you do it, but if you feel you want to take it on, feel free. Just make sure that the aliases in ucrtbase.def.in (or transitively from msvcrt-common.def.in) match api-ms-win-crt-*.def.in. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 00/10] crt: Move symbol aliases from CRT def files to msvcrt-common.def.in
On Wed, 24 Apr 2024, Martin Storsjö wrote: On Mon, 22 Apr 2024, Pali Rohár wrote: This patch series moves all aliases defined in crtdll.def.in, and msvcr*.def.in files into one common include file msvcrt-common.def.in. It reduces duplication of symbol alias definitions by defining symbols in more declarative manner. Moving aliases to one place uncovered that some def.in files were missing some alises (mostly for __ms_* printf/scanf symbols) or some were incorrectly defined (ctime for 64-bit msvcr90d.def.in was defined as alias to _ctime32 instead of _ctime64, or _findfirst for 64-bit msvcr120.def.in was defined as alias to symbol which does _not_ use 32-bit file length). For reference what this change affects, I'm attaching a difference which was generated for each CRT def.in file by command ($PLAT: DEF_I386 DEF_X64): cpp -x c -Wp,-w -undef -P -Imingw-w64-crt/def-include -D$PLAT | sed -E 's/\s*;.*//' | LC_ALL=C sort -u I presume you didn't diff the changes for ucrtbase.def.in? Because it seems to be changes that do affect the output from that one, in patch 10/10. I looked closely at patches 1-9, and they seemed fine, so if you can recheck that they don't affect the preprocessed output for ucrtbase as well, we could land them and look at polishing the last one a bit more. I checked that the output from preprocessing ucrtbase.def.in is unchanged by patches 1-9, so I pushed them. The output after patch 10 does change though, as expected, so I'll leave that one for now. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] winpthreads: Avoid using MemoryBarrier() in public headers with GCC/Clang
On Wed, 24 Apr 2024, LIU Hao wrote:
在 2024-04-24 20:11, Martin Storsjö 写道:
Agreed, although it's less of a regression if we require windows headers
for pthread_cleanup_push only when built with MSVC, than making it required
for everybody, as the library wasn't usable at all with MSVC until
recently.
However, I looked at the output of _ReadWriteBarrier(), and in most cases,
it seems like this doesn't seem like something equivalent to
__sync_synchronize. In the mingw headers, it's just defined as __asm__
__volatile__ ("" ::: "memory"), i.e. something that stops the compiler from
reordering code across this point, but does nothing for synchronizing with
other threads. See e.g. https://godbolt.org/z/ccGdd7P44.
I.e., for now, I still think this patch in the shape I posted it, is the
best candidate for unbreaking this case.
This reminds me that `MemoryBarrier()` is a full barrier (`atomic_seq_cst`)
instead of a load-store barrier (`atomic_acq_rel`)., and the barriers are
there to prevent partial writes in case of asynchronous cancellation.
The patch looks correct to me. Please go ahead and apply. Thanks.
Applied now, thanks!
// Martin
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH 3/5] headers: Don't redefine the __mingw_ovr define in swprintf.inl and wchar.h
This redefining of the macro was added in 824ceb1d1265e257d8b85d8e191f4db2a1e7735c, without an explanation of why that was done. If we really do need to use a different inline declaration for these functions, we should use a different macro, so we don't alter the meaning of the __mingw_ovr define after including swprintf.inl or wchar.h. This practically has the effect, that these inlines are declared as regular "inline" instead of "static __inline__" when built in C++ mode with a GCC compatible compiler. This matches how the __mingw_ovr macro is defined and used for many other inline functions. Signed-off-by: Martin Storsjö --- mingw-w64-headers/crt/swprintf.inl | 13 - mingw-w64-headers/crt/wchar.h | 13 - 2 files changed, 26 deletions(-) diff --git a/mingw-w64-headers/crt/swprintf.inl b/mingw-w64-headers/crt/swprintf.inl index 0d4904bcd..d990d428c 100644 --- a/mingw-w64-headers/crt/swprintf.inl +++ b/mingw-w64-headers/crt/swprintf.inl @@ -9,19 +9,6 @@ #include -#undef __mingw_ovr -#if defined (__GNUC__) -#define __mingw_ovr static __attribute__ ((__unused__)) __inline__ __cdecl -#ifdef __mingw_static_ovr -#undef __mingw_static_ovr -#define __mingw_static_ovr __mingw_ovr -#endif -#elif defined(__cplusplus) -#define __mingw_ovr inline __cdecl -#else -#define __mingw_ovr static __cdecl -#endif - __mingw_ovr /* __attribute__((__format__ (gnu_wprintf, 3, 0))) */ __MINGW_ATTRIB_NONNULL(3) int vswprintf (wchar_t *__stream, size_t __count, const wchar_t *__format, __builtin_va_list __local_argv) diff --git a/mingw-w64-headers/crt/wchar.h b/mingw-w64-headers/crt/wchar.h index 6d3b537c2..b1c103686 100644 --- a/mingw-w64-headers/crt/wchar.h +++ b/mingw-w64-headers/crt/wchar.h @@ -520,19 +520,6 @@ extern FILE (* __MINGW_IMP_SYMBOL(_iob))[];/* A pointer to an array of FILE */ int __cdecl __stdio_common_vfwscanf(unsigned __int64 options, FILE *file, const wchar_t *format, _locale_t locale, va_list valist); #endif -#undef __mingw_ovr -#if defined (__GNUC__) -#define __mingw_ovr static __attribute__ ((__unused__)) __inline__ __cdecl -#ifdef __mingw_static_ovr -#undef __mingw_static_ovr -#define __mingw_static_ovr __mingw_ovr -#endif -#elif defined(__cplusplus) -#define __mingw_ovr inline __cdecl -#else -#define __mingw_ovr static __cdecl -#endif - #if __USE_MINGW_ANSI_STDIO /* -- 2.34.1 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH 0/5] Support building the libc++ C++23 std module
Hi, If trying to build libc++'s C++23 std module on top of the mingw headers, this currently fails for a number of cases where the std module wants to reexport a number of functions from the underlying libc. In the case of mingw-w64's headers, many standard C functions are implemented as inline functions, and this fails if those functions are "static inline". Plain C++ "inline" works fine though. We do have the macro __mingw_ovr, which expands to "inline" in C++ mode, and "static inline" in C mode. This patchset avoids redefining __mingw_ovr in swprintf.inl and wchar.h, and applies this attribute instead of hardcoded "static inline" on a bunch of time functions, and mbsinit. With these patches in place, it's possible to build the libc++ C++23 std module on top of our headers. I guess non-static C++ inline can be problematic for functions that can be redefined based on macros, like _USE_32BIT_TIME_T or __USE_MINGW_ANSI_STDIO; if two object files in the same link both use the same standard C functions (for regular compilation and linking, not specific to C++ modules), but with these defines set differently, both object files will have their own conflicting definition of the inline function, and the linker is free to pick either of them and use it for both cases. On the other hand, given the widespread use of __mingw_ovr, this might be a preexisting issue in any case. But then again, due to headers like swprintf.inl and wchar.h redefining __mingw_ovr, it's possible that most functions never actually used the original form of __mingw_ovr at all? // Martin Martin Storsjö (5): crt: Use the right options in the UCRT non-inline _snwprintf headers: Remove UCRT inline fwprintf and _snwprintf headers: Don't redefine the __mingw_ovr define in swprintf.inl and wchar.h headers: Use __mingw_ovr instead of explicitly static inline headers: Stop using the __mingw_static_ovr macro mingw-w64-crt/stdio/ucrt__snwprintf.c | 2 +- mingw-w64-headers/crt/_mingw_mac.h| 4 --- mingw-w64-headers/crt/stdio.h | 30 - mingw-w64-headers/crt/swprintf.inl| 13 mingw-w64-headers/crt/time.h | 48 +-- mingw-w64-headers/crt/wchar.h | 37 ++--- 6 files changed, 34 insertions(+), 100 deletions(-) -- 2.34.1 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH 1/5] crt: Use the right options in the UCRT non-inline _snwprintf
In the inline form of _snwprintf, we set _CRT_INTERNAL_PRINTF_LEGACY_VSPRINTF_NULL_TERMINATION, but in the non-inline version, we just called vsnwprintf, which doesn't set that option. Instead call __stdio_common_vswprintf directly, with the right options. The previous form stemmed from the original UCRT implementation in bc6a87488995675ae80c312e3585cb1ace739b43. Signed-off-by: Martin Storsjö --- mingw-w64-crt/stdio/ucrt__snwprintf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mingw-w64-crt/stdio/ucrt__snwprintf.c b/mingw-w64-crt/stdio/ucrt__snwprintf.c index d4d5eff17..07cdf18a4 100644 --- a/mingw-w64-crt/stdio/ucrt__snwprintf.c +++ b/mingw-w64-crt/stdio/ucrt__snwprintf.c @@ -30,7 +30,7 @@ int __cdecl _snwprintf(wchar_t * restrict _Dest, size_t _Count, const wchar_t * va_list ap; int ret; va_start(ap, _Format); - ret = vsnwprintf(_Dest, _Count, _Format, ap); + ret = __stdio_common_vswprintf(_CRT_INTERNAL_LOCAL_PRINTF_OPTIONS | _CRT_INTERNAL_PRINTF_LEGACY_VSPRINTF_NULL_TERMINATION, _Dest, _Count, _Format, NULL, ap); va_end(ap); return ret; } -- 2.34.1 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH 5/5] headers: Stop using the __mingw_static_ovr macro
We should prefer using a macro which doesn't declare functions
as static inline in C++ mode.
This macro was added in bc6a87488995675ae80c312e3585cb1ace739b43,
without an explanation of why it was added.
Signed-off-by: Martin Storsjö
---
I guess it's possible that an explanation for why it was added was
mentioned somewhere in some review discussion, but I don't
remember it myself at least.
---
mingw-w64-headers/crt/_mingw_mac.h | 4
mingw-w64-headers/crt/stdio.h | 8
2 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/mingw-w64-headers/crt/_mingw_mac.h
b/mingw-w64-headers/crt/_mingw_mac.h
index 0186eaf20..9de143e5d 100644
--- a/mingw-w64-headers/crt/_mingw_mac.h
+++ b/mingw-w64-headers/crt/_mingw_mac.h
@@ -280,18 +280,14 @@
__attribute__((__format__(gnu_scanf, __format,__args)))
#undef __mingw_ovr
-#undef __mingw_static_ovr
#ifdef __cplusplus
# define __mingw_ovr inline __cdecl
-# define __mingw_static_ovr static __mingw_ovr
#elif defined (__GNUC__)
# define __mingw_ovr static \
__attribute__ ((__unused__)) __inline__ __cdecl
-# define __mingw_static_ovr __mingw_ovr
#else
# define __mingw_ovr static __cdecl
-# define __mingw_static_ovr __mingw_ovr
#endif /* __cplusplus */
#if __MINGW_GNUC_PREREQ(4, 3) || defined(__clang__)
diff --git a/mingw-w64-headers/crt/stdio.h b/mingw-w64-headers/crt/stdio.h
index a05eb0713..d9fb00498 100644
--- a/mingw-w64-headers/crt/stdio.h
+++ b/mingw-w64-headers/crt/stdio.h
@@ -661,16 +661,16 @@ int vsnprintf (char *__stream, size_t __n, const char
*__format, __builtin_va_li
_CRTIMP int __cdecl _fseeki64(FILE *_File,__int64 _Offset,int _Origin);
_CRTIMP __int64 __cdecl _ftelli64(FILE *_File);
#ifdef _UCRT
- __mingw_static_ovr int fseeko(FILE *_File, _off_t _Offset, int _Origin) {
+ __mingw_ovr int fseeko(FILE *_File, _off_t _Offset, int _Origin) {
return fseek(_File, _Offset, _Origin);
}
- __mingw_static_ovr int fseeko64(FILE *_File, _off64_t _Offset, int _Origin) {
+ __mingw_ovr int fseeko64(FILE *_File, _off64_t _Offset, int _Origin) {
return _fseeki64(_File, _Offset, _Origin);
}
- __mingw_static_ovr _off_t ftello(FILE *_File) {
+ __mingw_ovr _off_t ftello(FILE *_File) {
return ftell(_File);
}
- __mingw_static_ovr _off64_t ftello64(FILE *_File) {
+ __mingw_ovr _off64_t ftello64(FILE *_File) {
return _ftelli64(_File);
}
#else
--
2.34.1
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH 4/5] headers: Use __mingw_ovr instead of explicitly static inline
When building the C++23 std modules, at least with libc++, the
C++ module needs to reexport a number of standard C functions.
The regular libc++ headers (the ones used even if not using
C++ modules) do this, essentially:
namespace std {
using ::ctime;
}
Thus reexporting the regular C function ctime within the std
namespace.
When building libc++ as a module, this function gets emitted as
part of the C++ std module, like this:
export namespace std {
using std::ctime;
}
This tries to export the function as part of the C++ module. In the
case of our inline functions, this errors out if the inline functions
are static inline:
/share/libc++/v1/std/ctime.inc:20:14: error: using declaration
referring to 'ctime' with internal linkage cannot be exported
20 | using std::ctime;
| ^
/x86_64-w64-mingw32/include/time.h:267:29: note: target of using
declaration
267 | static __inline char *__CRTDECL ctime(const time_t *_Time) { return
_ctime64(_Time); }
| ^
Therefore, prefer using the __mingw_ovr macro for these inline
declarations. This macro expands to regular plain (non-static)
inline in C++ mode, while it still expands to static inline in C mode.
Signed-off-by: Martin Storsjö
---
mingw-w64-headers/crt/time.h | 48 +--
mingw-w64-headers/crt/wchar.h | 2 +-
2 files changed, 25 insertions(+), 25 deletions(-)
diff --git a/mingw-w64-headers/crt/time.h b/mingw-w64-headers/crt/time.h
index d70a70717..f8401903c 100644
--- a/mingw-w64-headers/crt/time.h
+++ b/mingw-w64-headers/crt/time.h
@@ -241,33 +241,33 @@ extern "C" {
#ifndef RC_INVOKED
#ifdef _USE_32BIT_TIME_T
-static __inline time_t __CRTDECL time(time_t *_Time) { return _time32(_Time); }
+__mingw_ovr time_t __CRTDECL time(time_t *_Time) { return _time32(_Time); }
#ifdef _UCRT
-static __inline int __CRTDECL timespec_get(struct timespec* _Ts, int _Base) {
return _timespec32_get((struct _timespec32*)_Ts, _Base); }
-#endif
-static __inline double __CRTDECL difftime(time_t _Time1,time_t _Time2) {
return _difftime32(_Time1,_Time2); }
-static __inline struct tm *__CRTDECL localtime(const time_t *_Time) { return
_localtime32(_Time); }
-static __inline errno_t __CRTDECL localtime_s(struct tm *_Tm,const time_t
*_Time) { return _localtime32_s(_Tm,_Time); }
-static __inline struct tm *__CRTDECL gmtime(const time_t *_Time) { return
_gmtime32(_Time); }
-static __inline errno_t __CRTDECL gmtime_s(struct tm *_Tm, const time_t
*_Time) { return _gmtime32_s(_Tm, _Time); }
-static __inline char *__CRTDECL ctime(const time_t *_Time) { return
_ctime32(_Time); }
-static __inline errno_t __CRTDECL ctime_s(char *_Buf,size_t _SizeInBytes,const
time_t *_Time) { return _ctime32_s(_Buf,_SizeInBytes,_Time); }
-static __inline time_t __CRTDECL mktime(struct tm *_Tm) { return
_mktime32(_Tm); }
-static __inline time_t __CRTDECL _mkgmtime(struct tm *_Tm) { return
_mkgmtime32(_Tm); }
+__mingw_ovr int __CRTDECL timespec_get(struct timespec* _Ts, int _Base) {
return _timespec32_get((struct _timespec32*)_Ts, _Base); }
+#endif
+__mingw_ovr double __CRTDECL difftime(time_t _Time1,time_t _Time2) { return
_difftime32(_Time1,_Time2); }
+__mingw_ovr struct tm *__CRTDECL localtime(const time_t *_Time) { return
_localtime32(_Time); }
+__mingw_ovr errno_t __CRTDECL localtime_s(struct tm *_Tm,const time_t *_Time)
{ return _localtime32_s(_Tm,_Time); }
+__mingw_ovr struct tm *__CRTDECL gmtime(const time_t *_Time) { return
_gmtime32(_Time); }
+__mingw_ovr errno_t __CRTDECL gmtime_s(struct tm *_Tm, const time_t *_Time)
{ return _gmtime32_s(_Tm, _Time); }
+__mingw_ovr char *__CRTDECL ctime(const time_t *_Time) { return
_ctime32(_Time); }
+__mingw_ovr errno_t __CRTDECL ctime_s(char *_Buf,size_t _SizeInBytes,const
time_t *_Time) { return _ctime32_s(_Buf,_SizeInBytes,_Time); }
+__mingw_ovr time_t __CRTDECL mktime(struct tm *_Tm) { return _mktime32(_Tm); }
+__mingw_ovr time_t __CRTDECL _mkgmtime(struct tm *_Tm) { return
_mkgmtime32(_Tm); }
#else
-static __inline time_t __CRTDECL time(time_t *_Time) { return _time64(_Time); }
+__mingw_ovr time_t __CRTDECL time(time_t *_Time) { return _time64(_Time); }
#ifdef _UCRT
-static __inline int __CRTDECL timespec_get(struct timespec* _Ts, int _Base) {
return _timespec64_get((struct _timespec64*)_Ts, _Base); }
-#endif
-static __inline double __CRTDECL difftime(time_t _Time1,time_t _Time2) {
return _difftime64(_Time1,_Time2); }
-static __inline struct tm *__CRTDECL localtime(const time_t *_Time) { return
_localtime64(_Time); }
-static __inline errno_t __CRTDECL localtime_s(struct tm *_Tm,const time_t
*_Time) { return _localtime64_s(_Tm,_Time); }
-static __inline struct tm *__CRTDECL gmtime(const time_t *_Time) { return
_gmtime64(_Time); }
-static __inline errno_t __CRTDECL gmtime_s(struct tm *_Tm, const time_t
*_Time) { return _gmtime64_s(_Tm, _Time); }
-static __inline char
[Mingw-w64-public] [PATCH 2/5] headers: Remove UCRT inline fwprintf and _snwprintf
We already have non-inline versions of these functions; use the
non-inline version consistently, to avoid potential cases of
inconsistency.
Signed-off-by: Martin Storsjö
---
mingw-w64-headers/crt/stdio.h | 22 ++
mingw-w64-headers/crt/wchar.h | 22 ++
2 files changed, 4 insertions(+), 40 deletions(-)
diff --git a/mingw-w64-headers/crt/stdio.h b/mingw-w64-headers/crt/stdio.h
index 9b4ab8275..a05eb0713 100644
--- a/mingw-w64-headers/crt/stdio.h
+++ b/mingw-w64-headers/crt/stdio.h
@@ -1240,16 +1240,7 @@ int vsnwprintf (wchar_t *__stream, size_t __n, const
wchar_t *__format, __builti
return __stdio_common_vfwscanf(_CRT_INTERNAL_LOCAL_SCANF_OPTIONS, stdin,
__format, NULL, __local_argv);
}
- __mingw_static_ovr
- int __cdecl fwprintf(FILE * __restrict__ _File,const wchar_t * __restrict__
_Format,...)
- {
-__builtin_va_list __ap;
-int __ret;
-__builtin_va_start(__ap, _Format);
-__ret = __stdio_common_vfwprintf(_CRT_INTERNAL_LOCAL_PRINTF_OPTIONS,
_File, _Format, NULL, __ap);
-__builtin_va_end(__ap);
-return __ret;
- }
+ int __cdecl fwprintf(FILE * __restrict__ _File,const wchar_t * __restrict__
_Format,...);
__mingw_ovr
int __cdecl wprintf(const wchar_t * __restrict__ _Format,...)
{
@@ -1344,16 +1335,7 @@ int vsnwprintf (wchar_t *__stream, size_t __n, const
wchar_t *__format, __builti
__builtin_va_end(__ap);
return __ret;
}
- __mingw_static_ovr __MINGW_ATTRIB_DEPRECATED_SEC_WARN
- int __cdecl _snwprintf(wchar_t * __restrict__ _Dest,size_t _Count,const
wchar_t * __restrict__ _Format,...)
- {
-__builtin_va_list __ap;
-int __ret;
-__builtin_va_start(__ap, _Format);
-__ret = __stdio_common_vswprintf(_CRT_INTERNAL_LOCAL_PRINTF_OPTIONS |
_CRT_INTERNAL_PRINTF_LEGACY_VSPRINTF_NULL_TERMINATION, _Dest, _Count, _Format,
NULL, __ap);
-__builtin_va_end(__ap);
-return __ret;
- }
+ int __cdecl _snwprintf(wchar_t * __restrict__ _Dest,size_t _Count,const
wchar_t * __restrict__ _Format,...) __MINGW_ATTRIB_DEPRECATED_SEC_WARN;
int __cdecl _vsnwprintf(wchar_t * __restrict__ _Dest,size_t _Count,const
wchar_t * __restrict__ _Format,va_list _Args)
__MINGW_ATTRIB_DEPRECATED_SEC_WARN;
#if __USE_MINGW_ANSI_STDIO == 0
diff --git a/mingw-w64-headers/crt/wchar.h b/mingw-w64-headers/crt/wchar.h
index 652b66354..6d3b537c2 100644
--- a/mingw-w64-headers/crt/wchar.h
+++ b/mingw-w64-headers/crt/wchar.h
@@ -704,16 +704,7 @@ int vsnwprintf (wchar_t *__stream, size_t __n, const
wchar_t *__format, __builti
return __stdio_common_vfwscanf(_CRT_INTERNAL_LOCAL_SCANF_OPTIONS, stdin,
__format, NULL, __local_argv);
}
- __mingw_static_ovr
- int __cdecl fwprintf(FILE * __restrict__ _File,const wchar_t * __restrict__
_Format,...)
- {
-__builtin_va_list __ap;
-int __ret;
-__builtin_va_start(__ap, _Format);
-__ret = __stdio_common_vfwprintf(_CRT_INTERNAL_LOCAL_PRINTF_OPTIONS,
_File, _Format, NULL, __ap);
-__builtin_va_end(__ap);
-return __ret;
- }
+ int __cdecl fwprintf(FILE * __restrict__ _File,const wchar_t * __restrict__
_Format,...);
__mingw_ovr
int __cdecl wprintf(const wchar_t * __restrict__ _Format,...)
{
@@ -809,16 +800,7 @@ int vsnwprintf (wchar_t *__stream, size_t __n, const
wchar_t *__format, __builti
__builtin_va_end(__ap);
return __ret;
}
- __mingw_static_ovr __MINGW_ATTRIB_DEPRECATED_SEC_WARN
- int __cdecl _snwprintf(wchar_t * __restrict__ _Dest,size_t _Count,const
wchar_t * __restrict__ _Format,...)
- {
-__builtin_va_list __ap;
-int __ret;
-__builtin_va_start(__ap, _Format);
-__ret = __stdio_common_vswprintf(_CRT_INTERNAL_LOCAL_PRINTF_OPTIONS |
_CRT_INTERNAL_PRINTF_LEGACY_VSPRINTF_NULL_TERMINATION, _Dest, _Count, _Format,
NULL, __ap);
-__builtin_va_end(__ap);
-return __ret;
- }
+ int __cdecl _snwprintf(wchar_t * __restrict__ _Dest,size_t _Count,const
wchar_t * __restrict__ _Format,...) __MINGW_ATTRIB_DEPRECATED_SEC_WARN;
__mingw_ovr __MINGW_ATTRIB_DEPRECATED_SEC_WARN
int __cdecl _vsnwprintf(wchar_t * __restrict__ _Dest,size_t _Count,const
wchar_t * __restrict__ _Format,va_list _Args)
{
--
2.34.1
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 10/10] crt: Move find, stat and time aliases to def-include/msvcrt-common.def.in
On Mon, 22 Apr 2024, Pali Rohár wrote: Add 4 new macros FIXED_SIZE_SYMBOLS, NO_I64_FIXED_SIZE, NO_FIXED_SIZE_64_ALIAS and NO_TIME_ALIAS to distinguish between different crt versions. --- .../def-include/msvcrt-common.def.in | 154 ++ mingw-w64-crt/lib-common/msvcr120_app.def.in | 33 +--- mingw-w64-crt/lib-common/msvcrt.def.in| 23 +-- mingw-w64-crt/lib-common/ucrtbase.def.in | 12 -- mingw-w64-crt/lib32/crtdll.def.in | 12 +- mingw-w64-crt/lib32/msvcr100.def.in | 18 -- mingw-w64-crt/lib32/msvcr110.def.in | 18 -- mingw-w64-crt/lib32/msvcr120.def.in | 14 -- mingw-w64-crt/lib32/msvcr120d.def.in | 14 -- mingw-w64-crt/lib32/msvcr70.def.in| 12 +- mingw-w64-crt/lib32/msvcr71.def.in| 12 +- mingw-w64-crt/lib32/msvcr80.def.in| 22 --- mingw-w64-crt/lib32/msvcr90.def.in| 18 -- mingw-w64-crt/lib32/msvcr90d.def.in | 17 -- mingw-w64-crt/lib32/msvcrt10.def.in | 12 +- mingw-w64-crt/lib32/msvcrt20.def.in | 13 +- mingw-w64-crt/lib32/msvcrt40.def.in | 12 +- mingw-w64-crt/lib64/msvcr100.def.in | 18 -- mingw-w64-crt/lib64/msvcr110.def.in | 18 -- mingw-w64-crt/lib64/msvcr120.def.in | 14 -- mingw-w64-crt/lib64/msvcr120d.def.in | 13 -- mingw-w64-crt/lib64/msvcr80.def.in| 22 --- mingw-w64-crt/lib64/msvcr90.def.in| 18 -- mingw-w64-crt/lib64/msvcr90d.def.in | 18 -- 24 files changed, 169 insertions(+), 368 deletions(-) diff --git a/mingw-w64-crt/def-include/msvcrt-common.def.in b/mingw-w64-crt/def-include/msvcrt-common.def.in index 3e2c674d3699..abca29686531 100644 --- a/mingw-w64-crt/def-include/msvcrt-common.def.in +++ b/mingw-w64-crt/def-include/msvcrt-common.def.in @@ -197,6 +197,160 @@ _strtoimax_l == _strtoi64_l _strtoumax_l == _strtoui64_l #endif +; This is list of find symbol aliases, every CRT library has either find symbols with SIZE suffix or without them +#ifdef FIXED_SIZE_SYMBOLS +F32(_findfirst32 == _findfirst) +F64(_findfirst64i32 == _findfirst) +#ifndef NO_I64_FIXED_SIZE +F32(_findfirst32i64 == _findfirsti64) +#ifndef NO_FIXED_SIZE_64_ALIAS +F64(_findfirst64 == _findfirsti64) +#endif +#endif +F32(_findnext32 == _findnext) +F64(_findnext64i32 == _findnext) +#ifndef NO_I64_FIXED_SIZE +F32(_findnext32i64 == _findnexti64) +#ifndef NO_FIXED_SIZE_64_ALIAS +F64(_findnext64 == _findnexti64) +#endif +#endif +#ifndef NO_WIDE_FIXED_SIZE +F32(_wfindfirst32 == _wfindfirst) +F64(_wfindfirst64i32 == _wfindfirst) +#ifndef NO_I64_FIXED_SIZE +F32(_wfindfirst32i64 == _wfindfirsti64) +#ifndef NO_FIXED_SIZE_64_ALIAS +F64(_wfindfirst64 == _wfindfirsti64) +#endif +#endif +F32(_wfindnext32 == _wfindnext) +F64(_wfindnext64i32 == _wfindnext) +#ifndef NO_I64_FIXED_SIZE +F32(_wfindnext32i64 == _wfindnexti64) +#ifndef NO_FIXED_SIZE_64_ALIAS +F64(_wfindnext64 == _wfindnexti64) +#endif +#endif +#endif +#else +F32(_findfirst == _findfirst32) +F64(_findfirst == _findfirst64i32) This is the case that gets used by ucrtbase.def.in, right? diff --git a/mingw-w64-crt/lib-common/ucrtbase.def.in b/mingw-w64-crt/lib-common/ucrtbase.def.in index 2d0552f277ef..c8fb1e33b1d7 100644 --- a/mingw-w64-crt/lib-common/ucrtbase.def.in +++ b/mingw-w64-crt/lib-common/ucrtbase.def.in @@ -327,12 +327,10 @@ _filelength _filelengthi64 _fileno _findclose -_findfirst == _findfirst64 Note how we unconditionally had these macros pointing at _findfirst64 in ucrt, regardless of architecture. Now I'm not positively sure that this is all strictly correct, but if it's wrong, I would prefer to fix it in a separate commit, not in a refactoring commit like this one. (Overall, on UCRT we default to 64 bit time_t even on 32 bit architectures.) However, if we do change the aliases in ucrtbase.def.in, we also need to update api-ms-win-crt-*.def.in as well, as we have similar declarations there, scattered over a dozen of smaller files. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 00/10] crt: Move symbol aliases from CRT def files to msvcrt-common.def.in
On Mon, 22 Apr 2024, Pali Rohár wrote: This patch series moves all aliases defined in crtdll.def.in, and msvcr*.def.in files into one common include file msvcrt-common.def.in. It reduces duplication of symbol alias definitions by defining symbols in more declarative manner. Moving aliases to one place uncovered that some def.in files were missing some alises (mostly for __ms_* printf/scanf symbols) or some were incorrectly defined (ctime for 64-bit msvcr90d.def.in was defined as alias to _ctime32 instead of _ctime64, or _findfirst for 64-bit msvcr120.def.in was defined as alias to symbol which does _not_ use 32-bit file length). For reference what this change affects, I'm attaching a difference which was generated for each CRT def.in file by command ($PLAT: DEF_I386 DEF_X64): cpp -x c -Wp,-w -undef -P -Imingw-w64-crt/def-include -D$PLAT | sed -E 's/\s*;.*//' | LC_ALL=C sort -u I presume you didn't diff the changes for ucrtbase.def.in? Because it seems to be changes that do affect the output from that one, in patch 10/10. I looked closely at patches 1-9, and they seemed fine, so if you can recheck that they don't affect the preprocessed output for ucrtbase as well, we could land them and look at polishing the last one a bit more. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] winpthreads: Avoid using MemoryBarrier() in public headers with GCC/Clang
On Wed, 24 Apr 2024, LIU Hao wrote:
在 2024-04-24 00:18, Antonin Décimo 写道:
I couldn't find the difference between MemoryBarrier and _ReadWriteBarrier.
Maybe the MemoryBarrier macro is available on more architectures than
_ReadWriteBarrier which is only documented for x86 and x64?
`MemoryBarrier()` is a macro defined in 'winnt.h'. As a rule of thumb I think
we had better avoid inclusion of Windows headers in our headers, especially
headers that may be included by standard libraries.
Agreed, although it's less of a regression if we require windows headers
for pthread_cleanup_push only when built with MSVC, than making it
required for everybody, as the library wasn't usable at all with MSVC
until recently.
However, I looked at the output of _ReadWriteBarrier(), and in most cases,
it seems like this doesn't seem like something equivalent to
__sync_synchronize. In the mingw headers, it's just defined as __asm__
__volatile__ ("" ::: "memory"), i.e. something that stops the compiler
from reordering code across this point, but does nothing for synchronizing
with other threads. See e.g. https://godbolt.org/z/ccGdd7P44.
I.e., for now, I still think this patch in the shape I posted it, is the
best candidate for unbreaking this case.
// Martin
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Rust test failure after some math functions were moved
On Tue, 16 Apr 2024, Jacek Caban wrote: But in this particular case, I think we may improve things on mingw-w64-crt side and move __sinl_internal to msvcr* importlibs. Something like the attached (untested) patch should help. Unfortunately, we can't really do this; __sinl_internal and __cosl_internal are used by both math/x86/sin.c and math/x86/cos.c, which are in src_msvcrt_common_add_x86 (i.e. in the msvcr* specific import libraries), but they're also used by math/x86/sinl.c and math/x86/cosl.c, which are in src_libmingwex_x86, because the long double form of them are needed even with UCRT. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] winpthreads: Avoid using MemoryBarrier() in public headers with GCC/Clang
On Tue, 23 Apr 2024, Martin Storsjö wrote: Commit f281f4969d332efc842b93da892c2e97084e403e changed pthread_cleanup_push() to use MemoryBarrier() instead of __sync_synchronize(), for various reasons - one of them being able to build winpthreads with MSVC. Unfortunately, this change had the effect of breaking user code, including winpthreads headers and using pthread_cleanup_push() without including Windows headers first, as the MemoryBarrier() intrinsic requires including headers to get it properly declared (both with GCC, Clang and MSVC). To avoid this issue, revert to __sync_synchronize() in the installed header, as long as it is included with a GCC compatible compiler. For MSVC, keep using MemoryBarrier(). Signed-off-by: Martin Storsjö --- Commit f281f4969d332efc842b93da892c2e97084e403e argues that __sync_synchronize is deprecated within GCC, so we could of course look into using a more recommended intrinsic instead; this is only an attempt to undo the breakage to user code. --- mingw-w64-libraries/winpthreads/include/pthread.h | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/mingw-w64-libraries/winpthreads/include/pthread.h b/mingw-w64-libraries/winpthreads/include/pthread.h index 93d7c11c3..b1b5c8165 100644 --- a/mingw-w64-libraries/winpthreads/include/pthread.h +++ b/mingw-w64-libraries/winpthreads/include/pthread.h @@ -208,13 +208,22 @@ struct _pthread_cleanup _pthread_cleanup *next; }; +/* Using MemoryBarrier() requires including Windows headers. User code + * may want to use pthread_cleanup_push without including Windows headers + * first, thus prefer GCC specific intrinsics where possible. */ +#ifdef __GNUC__ +#define __pthread_MemoryBarrier() __sync_synchronize() +#else +#define __pthread_MemoryBarrier() MemoryBarrier() Liu Hao also pointed out that we could use _ReadWriteBarrier() with MSVC, and that one doesn't seem to require including any header before it is usable. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH] winpthreads: Avoid using MemoryBarrier() in public headers with GCC/Clang
Commit f281f4969d332efc842b93da892c2e97084e403e changed
pthread_cleanup_push() to use MemoryBarrier() instead of
__sync_synchronize(), for various reasons - one of them being
able to build winpthreads with MSVC.
Unfortunately, this change had the effect of breaking user code,
including winpthreads headers and using pthread_cleanup_push()
without including Windows headers first, as the MemoryBarrier()
intrinsic requires including headers to get it properly declared
(both with GCC, Clang and MSVC).
To avoid this issue, revert to __sync_synchronize() in the
installed header, as long as it is included with a GCC compatible
compiler. For MSVC, keep using MemoryBarrier().
Signed-off-by: Martin Storsjö
---
Commit f281f4969d332efc842b93da892c2e97084e403e argues that
__sync_synchronize is deprecated within GCC, so we could of course
look into using a more recommended intrinsic instead; this
is only an attempt to undo the breakage to user code.
---
mingw-w64-libraries/winpthreads/include/pthread.h | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/mingw-w64-libraries/winpthreads/include/pthread.h
b/mingw-w64-libraries/winpthreads/include/pthread.h
index 93d7c11c3..b1b5c8165 100644
--- a/mingw-w64-libraries/winpthreads/include/pthread.h
+++ b/mingw-w64-libraries/winpthreads/include/pthread.h
@@ -208,13 +208,22 @@ struct _pthread_cleanup
_pthread_cleanup *next;
};
+/* Using MemoryBarrier() requires including Windows headers. User code
+ * may want to use pthread_cleanup_push without including Windows headers
+ * first, thus prefer GCC specific intrinsics where possible. */
+#ifdef __GNUC__
+#define __pthread_MemoryBarrier() __sync_synchronize()
+#else
+#define __pthread_MemoryBarrier() MemoryBarrier()
+#endif
+
#define pthread_cleanup_push(F, A) \
do {\
const _pthread_cleanup _pthread_cup = \
{ (F), (A), *pthread_getclean() }; \
-MemoryBarrier();\
+__pthread_MemoryBarrier(); \
*pthread_getclean() = (_pthread_cleanup *) &_pthread_cup; \
-MemoryBarrier();\
+__pthread_MemoryBarrier(); \
do {\
do {} while (0)
--
2.34.1
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 6/6] crt: msvcr80.def.in: Fix __fls_getvalue@4 and __fls_setvalue@8 symbols
On Mon, 22 Apr 2024, LIU Hao wrote: 在 2024-04-20 00:54, Pali Rohár 写道: Same change as in commit 9b17c3374aa9eb809938bbcf7cf37093e842a4a7 for the I386 msvcr80.def.in file. --- mingw-w64-crt/lib32/msvcr80.def.in | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Thanks for these patches. I have pushed them to master now. Thanks, they looked good to me too. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] crt: execv*/spawnv* const-correctness
On Fri, 19 Apr 2024, Nikita Kniazev wrote:
A "char**" pointer can't be implicitly converted to a "const char**"
pointer - see https://c-faq.com/ansi/constmismatch.html for the full
explanation for this issue.
The function arguments are not "const char**", they are "const char*
const*" so there is no issue.
That doesn't make any difference. The point is that non-const can be
implicitly converted to const, only applies on the outermost pointer
layer.
int execve_before(const char *_Filename,char *const _ArgList[],char *const
_Env[]);
int execve_after(const char *_Filename,const char *const _ArgList[],const
char *const _Env[]);
void foo(char** args, char** env)
{
execve_before("x", args, env);
execve_after("x", args, env);
}
https://godbolt.org/z/4Tx5j9KM9
Note how you run this example in C++ mode. As Liu Hao mentioned, the
rules for these conversions differ between C and C++.
If you convert your example to C, it gives loud warnings with Clang and is
a hard error with GCC.
https://godbolt.org/z/d7EsnK61x
So we gain conformance with MSVC, but lose conformance with POSIX. (OTOH,
our functions are named with leading underscores, which can motivate them
differing.)
AFAIK types (not even type-constness) are **not** a part of C ABI on any
known platform to me.
I didn't say it is an ABI break - it's not. It's an API break though.
// Martin
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] crt: execv*/spawnv* const-correctness
On Thu, 18 Apr 2024, Nikita Kniazev wrote:
From 0d9fb95b2c50a15a90276f67e7ec44c67cb1093b Mon Sep 17 00:00:00 2001
From: Nikita Kniazev
Date: Thu, 18 Apr 2024 03:37:48 +
Subject: [PATCH] crt: execv*/spawnv* const-correctness
Signed-off-by: Nikita Kniazev
---
mingw-w64-headers/crt/process.h | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/mingw-w64-headers/crt/process.h
b/mingw-w64-headers/crt/process.h
index 1ac39a064..8c35372a3 100644
--- a/mingw-w64-headers/crt/process.h
+++ b/mingw-w64-headers/crt/process.h
@@ -183,20 +183,20 @@ extern "C" {
stupid warnings, define them in POSIX way. This is save, because
those
methods do not return in success case, so that the return value is not
really dependent to its scalar width. */
- _CRTIMP int __cdecl execv(const char *_Filename,char *const _ArgList[])
__MINGW_ATTRIB_DEPRECATED_MSVC2005;
- _CRTIMP int __cdecl execve(const char *_Filename,char *const
_ArgList[],char *const _Env[]) __MINGW_ATTRIB_DEPRECATED_MSVC2005;
- _CRTIMP int __cdecl execvp(const char *_Filename,char *const _ArgList[])
__MINGW_ATTRIB_DEPRECATED_MSVC2005;
- _CRTIMP int __cdecl execvpe(const char *_Filename,char *const
_ArgList[],char *const _Env[]) __MINGW_ATTRIB_DEPRECATED_MSVC2005;
+ _CRTIMP int __cdecl execv(const char *_Filename,const char *const
_ArgList[]) __MINGW_ATTRIB_DEPRECATED_MSVC2005;
Thanks, I think this patch is correct, so I think we should apply it.
However, this is a quite subtle area, and this can actually cause breakage
in user code.
A "char**" pointer can't be implicitly converted to a "const char**"
pointer - see https://c-faq.com/ansi/constmismatch.html for the full
explanation for this issue.
That said, MSVC's header seem to have const applied on these pointers like
you suggest, already in ancient versions like MSVC 6, up to the latest
versions using UCRT. So therefore, the change certainly is motivated, and
reduces the amount of unnecessary differences to MSVC.
However, on the other side, the POSIX spec for the exec* family of
functions, declare them without const here:
https://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html
So we gain conformance with MSVC, but lose conformance with POSIX. (OTOH,
our functions are named with leading underscores, which can motivate them
differing.)
In any case, while correct, this change can (and probably will) definitely
break building some user code that has so far worked, depending on
language mode and warning strictness etc. (Code that is built with both
MSVC and mingw might not have such issues though as there already was a
divergence.)
// Martin
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 6/9] crt: msvcr80.def.in: Fix some some I386 symbol names which miss @SIZE suffix
On Fri, 19 Apr 2024, Martin Storsjö wrote: On Thu, 18 Apr 2024, Pali Rohár wrote: On Friday 19 April 2024 00:22:31 Martin Storsjö wrote: On Mon, 8 Apr 2024, Pali Rohár wrote: I386 symbols __CxxLongjmpUnwind, _adj_fdiv_m*, _adj_fdivr_m* and _seh_longjmp_unwind have @SIZE suffix in I386 version of msvcr80.dll. I presume this is not a case where the symbols have @size suffixes in the DLL itself (which does exist but is quite rare), but where they are stdcall functions and gendef deduces that they should have this suffix, right? Exactly, now I re-checked it. I sent this patch before you have figured out that issue. It might be good to reword this aspect of the commit message a little... Yes, makes sense. What about? I386 symbols __CxxLongjmpUnwind, _adj_fdiv_m*, _adj_fdivr_m* and _seh_longjmp_unwind use stdcall convention, so add @SIZE suffix for them into I386 version of def file for msvcr80.dll. Thanks, that sounds good. Also, this adds this suffix for _adj_fdiv_m* - wasn't this the symbol we checked that really shouldn't have such a suffix? Yes, that is truth. But as I wrote, I sent this patch before recheck. I have a fix for all _adj_fdiv_m* symbols in all def files. But I have it on top of the "Sort symbols" patch. And changing order of these patches requires nontrivial rebasing of everything... Right, I guess that's understandable. I guess we can apply this one then, with a commit message mentioning that we know that this bit isn't entirely right (practically, it's of course harmless either way), but it will be fixed in an upcoming commit. I pushed these last patches now. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 6/9] crt: msvcr80.def.in: Fix some some I386 symbol names which miss @SIZE suffix
On Thu, 18 Apr 2024, Pali Rohár wrote: On Friday 19 April 2024 00:22:31 Martin Storsjö wrote: On Mon, 8 Apr 2024, Pali Rohár wrote: I386 symbols __CxxLongjmpUnwind, _adj_fdiv_m*, _adj_fdivr_m* and _seh_longjmp_unwind have @SIZE suffix in I386 version of msvcr80.dll. I presume this is not a case where the symbols have @size suffixes in the DLL itself (which does exist but is quite rare), but where they are stdcall functions and gendef deduces that they should have this suffix, right? Exactly, now I re-checked it. I sent this patch before you have figured out that issue. It might be good to reword this aspect of the commit message a little... Yes, makes sense. What about? I386 symbols __CxxLongjmpUnwind, _adj_fdiv_m*, _adj_fdivr_m* and _seh_longjmp_unwind use stdcall convention, so add @SIZE suffix for them into I386 version of def file for msvcr80.dll. Thanks, that sounds good. Also, this adds this suffix for _adj_fdiv_m* - wasn't this the symbol we checked that really shouldn't have such a suffix? Yes, that is truth. But as I wrote, I sent this patch before recheck. I have a fix for all _adj_fdiv_m* symbols in all def files. But I have it on top of the "Sort symbols" patch. And changing order of these patches requires nontrivial rebasing of everything... Right, I guess that's understandable. I guess we can apply this one then, with a commit message mentioning that we know that this bit isn't entirely right (practically, it's of course harmless either way), but it will be fixed in an upcoming commit. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] crt: msvcr70.def.in: Add missing @SIZE suffixes and __CxxCallUnwindVecDtor
On Thu, 18 Apr 2024, Pali Rohár wrote: On Wednesday 17 April 2024 23:59:34 Martin Storsjö wrote: On Wed, 17 Apr 2024, Pali Rohár wrote: I agree, it is impossible to have it at C level. Or at least I have not found a way how to do it. What is possible is to call that function from assembler or via gcc inline assembly from C. True, that could be possible. Those fdiv symbols are already present in more def files, so I can prepare a patch for fixing them (to be undecorated) and adding comment with explanation about those symbols. Could you look at other patches on the list? I will put these fdiv symbol updates on top of other, to not generate new rebase conflicts. I can try to get around to them soon - I kinda lost track of a bit of them recently, after Liu Hao reviewed and merged a bunch of them. Ok, to make it easier here is list of changes which were not reviewed yet: https://sourceforge.net/p/mingw-w64/mailman/message/58760247/ (1 patch) https://sourceforge.net/p/mingw-w64/mailman/message/58757928/ (9 patches in series) Thanks, this was helpful! // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] crt: msvcrt.def.in: Fix ARM32 symbols
On Sun, 14 Apr 2024, Pali Rohár wrote: Symbols __CxxFrameHandler2, _freea_s, _get_pgmptr and _get_wpgmptr are not present in Windows RT 8.0 and neither in 8.1 versions of msvcrt.dll library. So mark them as X86-only. And additional symbol __jump_unwind is present in Windows RT 8.0 and 8.1, so put it into Windows 8 section as ARM-only. Also update comment about ARM32 C++ symbols, they fully matches Windows RT 8.0 and 8.1 versions. Inspected Windows RT 8.0 msvcrt.dll ARM32 has version string 7.0.9200.16384. And Windows RT 8.1 msvcrt.dll ARM32 has version string 7.0.9468.0. --- mingw-w64-crt/lib-common/msvcrt.def.in | 58 +++--- 1 file changed, 52 insertions(+), 6 deletions(-) Thanks, this patch LGTM, so I pushed it. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 8/9] crt: msvcr80.def.in: Sort symbols as are in original def file and document SP1 version
On Fri, 19 Apr 2024, Martin Storsjö wrote: On Mon, 8 Apr 2024, Pali Rohár wrote: --- mingw-w64-crt/lib32/msvcr80.def.in | 1443 ++-- mingw-w64-crt/lib64/msvcr80.def.in | 1311 + 2 files changed, 1376 insertions(+), 1378 deletions(-) I think the rest of this set of 9 patches looks good, except for patch 6 which I had comments about, so I'll apply the other ones. This one, sorting the symbols, probably depends on the outcome of patch 6, so I'll omit this one for now as well. Patch 9 also had to be skipped as I skipped patch 8 for now, but the rest of them should be pushed now. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 8/9] crt: msvcr80.def.in: Sort symbols as are in original def file and document SP1 version
On Mon, 8 Apr 2024, Pali Rohár wrote: --- mingw-w64-crt/lib32/msvcr80.def.in | 1443 ++-- mingw-w64-crt/lib64/msvcr80.def.in | 1311 + 2 files changed, 1376 insertions(+), 1378 deletions(-) I think the rest of this set of 9 patches looks good, except for patch 6 which I had comments about, so I'll apply the other ones. This one, sorting the symbols, probably depends on the outcome of patch 6, so I'll omit this one for now as well. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 6/9] crt: msvcr80.def.in: Fix some some I386 symbol names which miss @SIZE suffix
On Mon, 8 Apr 2024, Pali Rohár wrote: I386 symbols __CxxLongjmpUnwind, _adj_fdiv_m*, _adj_fdivr_m* and _seh_longjmp_unwind have @SIZE suffix in I386 version of msvcr80.dll. I presume this is not a case where the symbols have @size suffixes in the DLL itself (which does exist but is quite rare), but where they are stdcall functions and gendef deduces that they should have this suffix, right? It might be good to reword this aspect of the commit message a little... Also, this adds this suffix for _adj_fdiv_m* - wasn't this the symbol we checked that really shouldn't have such a suffix? // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Rust test failure after some math functions were moved
On Tue, 16 Apr 2024, philippe renon via Mingw-w64-public wrote: All this to ask whether that "breaking" change was intentional ? The change itself was quite intentional, the breakage obviously wasn't intentional. We have a fair bit of these kinds of circular dependencies between libmingwex.a and libmsvcr*.a. And we'll probably get more of them, not less, as we specialize some of our helper routines into different versions for different CRTs (like this change). So therefore, breakage of this kind is indeed not surprising, when linking with ld.bfd, if the libs aren't specified repeatedly. When driving linking with GCC and Clang, the linker is already invoked with multiple "-lmsvcrt -lmingwex [..] -lmsvcrt -lmingwex". There are also other similar issues that we've had to fix by adding more of these duplicate linker options, see e.g. https://github.com/gcc-mirror/gcc/commit/850533ab160ef40eccfd039e1e3b138cf26e76b8. This is not an issue with lld, because it scans for symbols in all loaded libraries, not in the strict sequential manner that ld.bfd does. Alternatively, instead of just repeating these linker options over and over, we could consider to add --start-group --end-group around these linker options, in GCC, Clang and Rust, which would allow resolving any of the dependencies in these libraries among themselves. Clang already passes this, see e.g. https://github.com/llvm/llvm-project/blob/llvmorg-18.1.4/clang/lib/Driver/ToolChains/MinGW.cpp#L277-L348, but it only seems to do this when intending to link statically. Perhaps this should be done unconditionally - this is already done for some targets, see e.g. https://github.com/llvm/llvm-project/blob/llvmorg-18.1.4/clang/lib/Driver/ToolChains/NaCl.cpp#L146-L147. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] crt: msvcr70.def.in: Add missing @SIZE suffixes and __CxxCallUnwindVecDtor
On Wed, 17 Apr 2024, Pali Rohár wrote: I agree, it is impossible to have it at C level. Or at least I have not found a way how to do it. What is possible is to call that function from assembler or via gcc inline assembly from C. True, that could be possible. Those fdiv symbols are already present in more def files, so I can prepare a patch for fixing them (to be undecorated) and adding comment with explanation about those symbols. Could you look at other patches on the list? I will put these fdiv symbol updates on top of other, to not generate new rebase conflicts. I can try to get around to them soon - I kinda lost track of a bit of them recently, after Liu Hao reviewed and merged a bunch of them. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 2/2] crt: Fix some symbols with duplicate stdcall suffixes
On Tue, 16 Apr 2024, LIU Hao wrote: 在 2024-04-16 15:30, Martin Storsjö 写道: I'm not at all familiar with these APIs and DLLs, so I don't quite know what the best way forward is. But the fact that the same functions can be declared with different calling conventions is indeed a bit of a problem. If nobody really are using the files, it's probably ok to just remove them, or remove the symbols and leave comments explaining the sitaution. Well, I think this awkward DEF should be kept for backward compatibility. An updated patch is attached. Thanks, I think this one looks reasonable. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 2/2] crt: Fix some symbols with duplicate stdcall suffixes
On Tue, 16 Apr 2024, LIU Hao wrote: 在 2024-04-16 05:19, Martin Storsjö 写道: Hmm, I would prefer if you'd add a new macro for this purpose, instead of reusing the old one. The old existing one is used to add aliases for functions, usually like this: --- _somefunc ADD_UNDERSCORE(somefunc) --- But here, you're adding an alias as a way to specify the literal DLL import name, as a way to undo the effect of dlltool's "-k" option for one single symbol. So I see it semantically as a different thing, so a new macro, e.g. "LITERAL_STDCALL(somefunc@4)" instead. Or maybe KEEP_STDCALL() or something like that? (The reason why I want to make the distinction, is both because I feel that it's semantically a different thing, but also because llvm-dlltool doesn't handle this exact case right now, it only works with the aliases in the former style. But I think it should be possible to improve llvm-dlltool to make this case work as well.)' Yes, this is indeed abuse. I can add a macro for MSVCR* DLLs, but, this patch includes a hunk for 'x3daudio1_2.def', which is consumed without `-DDEF_I386` etc. I have an impression that 'lib32/*.def' should not use those macros. We can either spell it out manually, like what we have currently in x3daudio1_2.def (I guess the main bug there is that it should be "X3DAudioCalculate@20 == _X3DAudioCalculate@20" without the leading "_" at the start of the line?). Or rename the file to .def.in; there's nothing saying that we can't use .def file preprocessing for files in lib32, it's just that we haven't really usually needed it so far. And not only is 'x3daudio1_2.def', the only two functions which it exports have changed to __cdecl, and require an incompatible header (which doesn't exist however). Another option would be to just drop this file. Yes, that bit seems like a big mess too. I'm not at all familiar with these APIs and DLLs, so I don't quite know what the best way forward is. But the fact that the same functions can be declared with different calling conventions is indeed a bit of a problem. If nobody really are using the files, it's probably ok to just remove them, or remove the symbols and leave comments explaining the sitaution. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] crt: msvcr70.def.in: Add missing @SIZE suffixes and __CxxCallUnwindVecDtor
On Tue, 16 Apr 2024, LIU Hao wrote: I think it is better to be compatible with MSVC object level behavior than inventing new/custom object level behavior. Meaning to export it from def file without @SIZE. But I think it is not possible to write declaration for this function into header file. Because __attribute__((stdcall)) annotation cause that all arguments are passed via stack. I looked at gcc documentation https://gcc.gnu.org/onlinedocs/gcc/x86-Function-Attributes.html and there is nothing which can tell to gcc compiler that first floating point argument is passed in x87 register instead of the stack. Maybe clang supports something? I don't think it supports something for this case. If these are functions necessary by the Microsoft compiler (random posts on Google suggest they have been there to work around the Intel division bug) and not meant to be called by users, maybe we just shouldn't provide them. Indeed, this doesn't look like a regular function that we can add a C level declaration for, but only for use with compiler generated special calls. (This is similar to e.g. the __chkstk family of functions; each of these use a quite custom ABI/calling convention, different on each architecture, and only possible to use in compiler generated calls generally.) So I would agree that if we should list it at all, it should be undecorated, to match MSVC. I guess your main goal is to document what symbols each version of msvcr*.dll have and make our def files match that as closely as possible. So for that purpose, we could also just include it, even if nobody is going to reference it. Or leave it out (just keeping comments explaining it). I don't have a strong opinion either way. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 1/2] crt/xaudio2_9: Fix export names of `X3DAudioCalculate` and `X3DAudioInitialize`
On Mon, 15 Apr 2024, LIU Hao wrote: -- Thanks, I think this patch (1/2) is fine. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 2/2] crt: Fix some symbols with duplicate stdcall suffixes
On Tue, 16 Apr 2024, LIU Hao wrote: 1. There is currently no 'x3daudio.h' in mingw-w64. Wine and Windows SDK headers have `X3DAudioInitialize()` and `X3DAudioCalculate()` as `__cdecl`, but they are really `__stdcall` in X3DAUDIO1_2.DLL. 2. The macros `ADD_UNDERSCORE()` and `ADD_DOUBLE_UNDERSCORE()` are moved from 'msvcrt-common.def.in' to 'func.def.in' so they can be reused. Previously they were only used by 'msvcr*.def.in'. Hmm, I would prefer if you'd add a new macro for this purpose, instead of reusing the old one. The old existing one is used to add aliases for functions, usually like this: --- _somefunc ADD_UNDERSCORE(somefunc) --- But here, you're adding an alias as a way to specify the literal DLL import name, as a way to undo the effect of dlltool's "-k" option for one single symbol. So I see it semantically as a different thing, so a new macro, e.g. "LITERAL_STDCALL(somefunc@4)" instead. Or maybe KEEP_STDCALL() or something like that? (The reason why I want to make the distinction, is both because I feel that it's semantically a different thing, but also because llvm-dlltool doesn't handle this exact case right now, it only works with the aliases in the former style. But I think it should be possible to improve llvm-dlltool to make this case work as well.) // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] crt: msvcr70.def.in: Add missing @SIZE suffixes and __CxxCallUnwindVecDtor
On Mon, 15 Apr 2024, Pali Rohár wrote:
On Monday 15 April 2024 10:49:43 Martin Storsjö wrote:
Or just compiling a test C file with the corresponding
MSVC version and looking at the generated object file to see what symbol
reference it generated.
So... now I did an experiment with VC4.2 CL.EXE (first version which
generate code for msvcrt.dll) and VC4.1 CL.EXE (last version which
generate code for msvcr40.dll).
Source code:
float __cdecl fdiv(float a, float b) { return a / b; }
Compiled with:
CL.EXE /c /QIfdiv /O2
Both 4.1 and 4.2 versions of CL.EXE generated same obj file which under
objdump -dr looks like:
Disassembly of section .text:
<_fdiv>:
0: d9 44 24 04 flds 0x4(%esp)
4: 83 3d 00 00 00 00 00cmpl $0x0,0x0
6: dir32__adjust_fdiv
b: 75 06 jne13 <_fdiv+0x13>
d: d8 74 24 08 fdivs 0x8(%esp)
11: eb 09 jmp1c <_fdiv+0x1c>
13: ff 74 24 08 pushl 0x8(%esp)
17: e8 00 00 00 00 call 1c <_fdiv+0x1c>
18: DISP32 __adj_fdiv_m32
1c: c3 ret
So what does it say about __adjust_fdiv and __adj_fdiv_m32 symbols?
If my understanding is correct then __adjust_fdiv is global variable
Yes, I would agree about that
and __adj_fdiv_m32 is a function which takes first float argument in x87
ST(0) register, second float argument on the stack and function itself
pops the stack (the second float argument).
This seems to be true as well, yes. I.e. the function uses stdcall calling
convention.
Now I checked all versions of msvcrt40.dll libraries which I found
(including OS system versions) and all have symbol name "_adj_fdiv_m32"
in their import tables.
Ok, so that would correspond to the same pattern as many of these others,
that the DLL exports an undecorated name.
So does it mean that "_adj_fdiv_m32" (and possibly also all other _adj_*
symbols) use stdcall calling convention, and should be defined with
@SIZE suffix in the .def file?
Hmm, maybe.
If _adj_fdiv_m32 would be a regular C function, it should be declared
stdcall, in order to get the stack adjustment behaviour you described. But
if you'd have a stdcall function, then the object file level references to
it would be "__adj_fdiv_m32@4" as well - but the MSVC produced object file
doesn't have that.
So it seems to me that this isn't a regular C level function in any case,
but the compiler generates calls, with the stdcall calling convention, but
without stdcall name mangling on the symbol. And there's no declaration of
the function in any header, as it's not meant to be called as such, only
called by compiler generated code.
So exactly what we place in our def file is pretty much up to us in that
case. If we would add a declaration of the function in our headers, we'd
need to declare it stdcall - then the object file level name would include
the @size, and we'd need to place this in the def file.
But if we'd want to match the MSVC object level behaviour for this
function, we could also keep the name in the def file undecorated. If we'd
have a declaration in a header, we could add an asm("") name to it, to
signify that even if the function is stdcall, the symbol name is
different.
But as the function isn't meant to be called from user C code, we might
not need to do that at all. So we could just leave it without the @size
part, matching MSVC, and if we'd make GCC or Clang generate calls to it,
we'd make them generate calls to "__adj_fdiv_m32" without the @size, just
like MSVC did.
So all in all, this looks like a special case function, and there's no
clear answer what we should place in the def file. I would maybe prefer
keeping it without @size as that's how MSVC references it (but I don't
have a strong opinion on it), and then add a comment that it's an odd
stdcall function without the typical stdcall suffix on the symbol name.
// Martin
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] crt: msvcr70.def.in: Add missing @SIZE suffixes and __CxxCallUnwindVecDtor
On Mon, 15 Apr 2024, Pali Rohár wrote: These functions are exported on the DLL interface as plain "name". When we call them, via a declaration marked as stdcall in C, it does produce a call to the symbol "_name@size" instead of the regular "_name". This information is not visible on the external DLL interface at all. I was totally confused how it works. And now I figured out that import libraries in mingw-w64 repository are generated with -k (--kill-at) parameter for dlltool, which removes that @SIZE suffix from the symbol name which is put into import table of the executable. In past I generated import libraries from def files without -k argument which seems that use 1:1 mapping between symbol in def file and in import table. Indeed, it's possible to use dlltool that way, but then it'd be pretty messy to generate import libraries that work for these kinds of DLLs. Gendef tries to look at the actual contents of the function, and uses heuristics to guess whether the function uses stdcall or cdecl calling convention. It's not foolproof though, as Liu Hao pointed out. objdump only looks at the DLL export table, and I presume readpe does that as well. So... if I understand it correctly then gendef tries to generate def file which has to be processed by -k (--kill-at) argument of dlltool. Yes, exactly. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] crt: msvcr70.def.in: Add missing @SIZE suffixes and __CxxCallUnwindVecDtor
On Mon, 15 Apr 2024, Pali Rohár wrote: On Monday 15 April 2024 09:19:09 LIU Hao wrote: 在 2024-04-15 04:52, Pali Rohár 写道: Symbols _assert@4 and abort@4 in all versions of msvcr70.dll have @SIZE suffixes. Without @SIZE suffixes they are only in debug msvcr70d.dll library versions and Itanium msvcr70.dll versions. I think these are kinda false positives. The stdcall suffixes are deduced by gendef from machine code, and are not part of the actual export name. These functions do not return and might have no meaningful RET instructions. Ou. Now I checked export names via objdump and rechecked also via readpe. And both tools say that they are without @SIZE suffix. Checking with objdump won't ever show a @size suffix, and I presume readpe does the same. These functions are exported on the DLL interface as plain "name". When we call them, via a declaration marked as stdcall in C, it does produce a call to the symbol "_name@size" instead of the regular "_name". This information is not visible on the external DLL interface at all. Gendef tries to look at the actual contents of the function, and uses heuristics to guess whether the function uses stdcall or cdecl calling convention. It's not foolproof though, as Liu Hao pointed out. objdump only looks at the DLL export table, and I presume readpe does that as well. So other than that, we can only look at the declarations in C headers. In this case, looking at our own headers might not help if it's not up to date for exactly this msvcrt DLL though, but looking at the corresponding MSVC header might help. (Or just compiling a test C file with the corresponding MSVC version and looking at the generated object file to see what symbol reference it generated.) This doesn't help for undocumented/undeclared private symbols though. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 5/5] crt: msvcrt.def.in: Fix aliases for time related symbols on X64
On Fri, 5 Apr 2024, Pali Rohár wrote: As this patchset depends a bit on some of the unapplied parts of the previous set, I'll defer applying it until all parts o the previous set has landed. // Martin Thanks for review of all patches! Now I have sent a new version of all patches which were not applied yet. I addresses issues about which you pointed and some patches I squashed. Thanks - these new patches all looked good (in an admittedly quite quick re-read), so I went ahead and pushed them. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 5/5] crt: msvcrt.def.in: Fix aliases for time related symbols on X64
On Thu, 4 Apr 2024, Pali Rohár wrote: Windows XP x64 does not provide 32-bit time functions. Those are provided on X64 systems since Windows Vista x64. Main function symbols (those without suffixes) are 64-bit on all Windows x64 systems. So remove aliasing of X64 "time" symbol to "_time64" symbol as it is not needed. Symbol "_difftime64" was added in Windows Vista. So for compatibility with Windows XP x64, define "_difftime64" symbol as alias to "difftime". Both symbols have same functionality. And export _ctime32, _mktime32, _time32 and _wctime32 symbols also on X64 version of msvcrt.dll as they are available since Windows Vista for both I386 and X64. Note that they are not available on Windows XP x64, but there is no reason to not export them (because mingw-w64 crt does not provide any fallback replacement implementation). --- mingw-w64-crt/lib-common/msvcrt.def.in | 22 +++--- 1 file changed, 7 insertions(+), 15 deletions(-) diff --git a/mingw-w64-crt/lib-common/msvcrt.def.in b/mingw-w64-crt/lib-common/msvcrt.def.in index ffc2812b92ac..c3dc34745aef 100644 --- a/mingw-w64-crt/lib-common/msvcrt.def.in +++ b/mingw-w64-crt/lib-common/msvcrt.def.in @@ -952,7 +952,7 @@ swscanf system tan tanh ; if we implement tanh, we can set it to DATA only. -time F_NON_I386(== _time64) +time Note that this change isn't a no-op as intended. On arm32, the unsuffixed "time" function is a 32 bit form, so previously, at link time, the "time" symbol used to resolve to a 64 bit form, now it is a 32 bit one. But I think this is the right thing to do anyway, and the previous behaviour looks like a bug. In practice, it probably doesn't make any difference in practice as time() usually is called via an inline function that redirects to _time32 or _time64 anyway. With that noted, I think this patch (and the rest of this set) looks ok. But it would be good to mention this aspect of the change in the commit message. (I guess I can edit it before applying too, if I remember.) As this patchset depends a bit on some of the unapplied parts of the previous set, I'll defer applying it until all parts o the previous set has landed. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 12/15] crt: msvcrt.def.in: Add symbols introduced in Windows Vista I386 and X64
On Thu, 4 Apr 2024, Pali Rohár wrote: On Friday 05 April 2024 00:02:02 Martin Storsjö wrote: On Mon, 1 Apr 2024, Pali Rohár wrote: --- mingw-w64-crt/lib-common/msvcrt.def.in | 136 - 1 file changed, 88 insertions(+), 48 deletions(-) diff --git a/mingw-w64-crt/lib-common/msvcrt.def.in b/mingw-w64-crt/lib-common/msvcrt.def.in index 818d5149b156..71a6efcde3c9 100644 --- a/mingw-w64-crt/lib-common/msvcrt.def.in +++ b/mingw-w64-crt/lib-common/msvcrt.def.in @@ -369,12 +369,14 @@ _XcptFilter F_ARM_ANY(__AdjustPointer) F_NON_I386(__C_specific_handler) __CppXcptFilter +F_X86_ANY(__CxxCallUnwindDelDtor) F_I386(__CxxCallUnwindDtor) F_I386(__CxxCallUnwindVecDtor) F_I386(__CxxDetectRethrow) F_I386(__CxxExceptionFilter) F_X86_ANY(__CxxFrameHandler) -F_ARM_ANY(__CxxFrameHandler3) +__CxxFrameHandler2 +__CxxFrameHandler3 F_I386(__CxxLongjmpUnwind@4) F_I386(__CxxQueryExceptionSize) F_I386(__CxxRegisterExceptionObject) @@ -403,10 +405,10 @@ __crtGetLocaleInfoW __crtGetStringTypeW __crtLCMapStringA __crtLCMapStringW -F_ARM_ANY(__daylight) +__daylight __dllonexit __doserrno -F_ARM_ANY(__dstbias) +__dstbias These two symbols, __daylight and __dstbias, probably should be marked DATA (based on their declaration in headers at least). __daylight and __dstbias (with two leading underlines) are regular functions, not global variables. mingw-w64-crt does not provide its own replacement version for these functions. No other def file marks them as DATA and neither gendef does not detect these symbols as DATA in any my examined msvcrt.dll version. So why should they be marked as DATA? Sorry, I conflated them with the single-underscore _daylight and _dstbias. Then this patch too should be fine, so I pushed it. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] crt: Use LoadLibraryA() in delayimp.c for char* type
On Mon, 1 Apr 2024, Pali Rohár wrote:
dli.szDll is of LPCSTR type, which is always const char* (and not wchar_t*).
So instead of LoadLibrary() (which may take wchar_t* if _UNICODE macro is
defined by compiler) use LoadLibraryA() (which always takes char*).
---
mingw-w64-crt/misc/delayimp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mingw-w64-crt/misc/delayimp.c b/mingw-w64-crt/misc/delayimp.c
index ca4b51ad161d..caa6166f066a 100644
--- a/mingw-w64-crt/misc/delayimp.c
+++ b/mingw-w64-crt/misc/delayimp.c
@@ -177,7 +177,7 @@ FARPROC WINAPI __delayLoadHelper2(PCImgDelayDescr
pidd,FARPROC *ppfnIATEntry)
if(hmod==0) {
if(__pfnDliNotifyHook2)
hmod = (HMODULE) (((*__pfnDliNotifyHook2)(dliNotePreLoadLibrary,)));
-if(hmod==0) hmod = LoadLibrary(dli.szDll);
+if(hmod==0) hmod = LoadLibraryA(dli.szDll);
if(hmod==0) {
dli.dwLastError = GetLastError();
if(__pfnDliFailureHook2)
--
2.20.1
LGTM, pushed. Thanks!
// Martin
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 01/15] crt: msvcrt.def.in: Add I386 C++ symbols
On Mon, 1 Apr 2024, Pali Rohár wrote: In msvcrt.def.in file are already defined mangled C++ symbols for X64 and ARM32 versions of msvcrt.dll, so add also them for I386 version. These symbols are present in Visual C++ 4.2 version of msvcrt.dll and same set of symbols are in Visual C++ 5.0 and 6.0 versions. --- mingw-w64-crt/lib-common/msvcrt.def.in | 101 + 1 file changed, 101 insertions(+) Except for the patches I commented on, in this 15 patch series, the rest seemed reasonable, so I pushed most of them. I omitted patch 4, 12 and 15 that I had comments on, and 14 which conflicted due to omitting those earlier patches. Thanks for these patches! // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 15/15] crt: msvcrt.def.in: Reorder symbols chronologically and add comments
On Mon, 1 Apr 2024, Pali Rohár wrote: Library msvcrt.dll was used by Visual C++ versions 4.2 - 6.0 and is also part of the Windows system starting with NT 4.0 and 98. Currently the file msvcrt.def.in contains mix of all symbols in semi alphabetical order, with ad-hoc symbol aliases which some are not exported by any msvcrt.dll version (but needed for mingw-w64). Cleanup symbol definitions, reorder them into chronological order according to released msvcrt.dll versions and add exhausting comments explaining from which msvcrt.dll version is symbol present and also if it is being replaced by other symbol at linking time for backward version compatibility reasons. If at symbol line is comment "replaced by" it means that the symbol is I think this sentence (and the next one) is easier to read if you'd add the word "there" before "is", i.e. "there is comment". Adding some a/an makes it a bit more legible English as well, and rephrasing a little, e.g. "If there is a comment "replaced by" at a symbol line, it means ..." +_endthread ; In Windows XP and Windows XP SP1 OS system version of msvcrt.dll this symbol has name _endthread@4, in all other versions (including XP SP3) is has standard name +_endthreadex ; In Windows XP and Windows XP SP1 OS system version of msvcrt.dll this symbol has name _endthreadex@4, in all other versions (including XP SP3) is has standard name There's a typo in these ocmments, "is has standard name", I guess you mean "it has standard name". +; This is list of additional symbol aliases not available in any CRT library +; FIXME: should they be removed? +F32(_ftime_s == _ftime32_s) +F64(_ftime_s == _ftime64_s) +snwprintf == _snwprintf +vsnwprintf == _vsnwprintf I would maybe remove the implication that these maybe should be removed, or rephrase the fixme, like e.g. "FIXME: check if these really are needed" or so. + +; This is list of some symbols from X86 version of libmingwex library which can be defined on ARM as alias to some msvcrt.dll symbols FWIW, the reason here is that on arm, long double is equal to regular double, so we don't need to provide our own replacements for these functions. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 12/15] crt: msvcrt.def.in: Add symbols introduced in Windows Vista I386 and X64
On Mon, 1 Apr 2024, Pali Rohár wrote: --- mingw-w64-crt/lib-common/msvcrt.def.in | 136 - 1 file changed, 88 insertions(+), 48 deletions(-) diff --git a/mingw-w64-crt/lib-common/msvcrt.def.in b/mingw-w64-crt/lib-common/msvcrt.def.in index 818d5149b156..71a6efcde3c9 100644 --- a/mingw-w64-crt/lib-common/msvcrt.def.in +++ b/mingw-w64-crt/lib-common/msvcrt.def.in @@ -369,12 +369,14 @@ _XcptFilter F_ARM_ANY(__AdjustPointer) F_NON_I386(__C_specific_handler) __CppXcptFilter +F_X86_ANY(__CxxCallUnwindDelDtor) F_I386(__CxxCallUnwindDtor) F_I386(__CxxCallUnwindVecDtor) F_I386(__CxxDetectRethrow) F_I386(__CxxExceptionFilter) F_X86_ANY(__CxxFrameHandler) -F_ARM_ANY(__CxxFrameHandler3) +__CxxFrameHandler2 +__CxxFrameHandler3 F_I386(__CxxLongjmpUnwind@4) F_I386(__CxxQueryExceptionSize) F_I386(__CxxRegisterExceptionObject) @@ -403,10 +405,10 @@ __crtGetLocaleInfoW __crtGetStringTypeW __crtLCMapStringA __crtLCMapStringW -F_ARM_ANY(__daylight) +__daylight __dllonexit __doserrno -F_ARM_ANY(__dstbias) +__dstbias These two symbols, __daylight and __dstbias, probably should be marked DATA (based on their declaration in headers at least). // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 06/15] crt: msvcrt.def.in: Do not export symbol wcsnlen on I386 and X64
On Mon, 1 Apr 2024, Pali Rohár wrote: Symbol wcsnlen was first introduced in Windows Vista version of msvcrt.dll and mingw-w64 already provides replacement implementation in libmingwex. So always use the replacement implementation on I386 and X64 and do not export it. Also remove DATA keyword and use it in the same way as other wc* symbols like wcsrtombs. --- mingw-w64-crt/lib-common/msvcrt.def.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mingw-w64-crt/lib-common/msvcrt.def.in b/mingw-w64-crt/lib-common/msvcrt.def.in index af9405c45d41..126097187f69 100644 --- a/mingw-w64-crt/lib-common/msvcrt.def.in +++ b/mingw-w64-crt/lib-common/msvcrt.def.in @@ -1703,7 +1703,7 @@ wcsncmp wcsncpy wcsncpy_s ; We provide replacement implementation in libmingwex -wcsnlen DATA +F_ARM_ANY(wcsnlen) FWIW, this looks reasonable. The UCRT import libraries (ucrtbase.def.in and api-ms-win-crt-string-l1-1-0.def) have copied the ; We provide replacement implementation in libmingwex wcsnlen DATA pattern here (as this marking in msvcrt.def.in didn't say why we're replacing this function). With your rationale in mind, we could probably remove that marker and "DATA" attribute from those def files, to allow the real UCRT version to be used. We could also consider moving this function from libmingwex into the libmsvcr* import libraries instead, to reduce the amount of unnecessary statically linked functions in UCRT configurations. (In principle, we could also make it specific to the x86 versions of msvcr*, as we can rely on this being present on ARM.) To be clear - this isn't a blocker for this patch, it looks reasonable on its own, but we (any of us) probably should clear this up for UCRT at least. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 04/15] crt: msvcrt.def.in: Export _Crt* symbols also on I386 and X64
On Mon, 1 Apr 2024, Pali Rohár wrote: They are present in msvcrt.dll since Windows Vista. --- mingw-w64-crt/lib-common/msvcrt.def.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mingw-w64-crt/lib-common/msvcrt.def.in b/mingw-w64-crt/lib-common/msvcrt.def.in index 460a1bab097b..5b2f4ddb2f08 100644 --- a/mingw-w64-crt/lib-common/msvcrt.def.in +++ b/mingw-w64-crt/lib-common/msvcrt.def.in @@ -299,7 +299,7 @@ __ExceptionPtrToBool ?what@exception@@UBAPBDXZ #endif -#ifdef DEF_ARM32 +#if defined(DEF_ARM32) || defined(DEF_I386) || defined(DEF_X64) I'd rather remove the ifdef altogether. If they're available on those three architectures, they're quite likely available on arm64 as well. And I just checked; the arm64 version of msvcrt.dll also does contain these symbols. The reason for this discrepancy to begin with, was that most of these def files have started from dumps of different versions of msvcrt.dll; the arm32 dump was made from a much newer version that the other ones. For arm64, we've not really done any bulk import from dumps at all. When arm64 became relevant, we instead unified the common similar bits from i386/x86_64/arm32 (leading to a shared file with these symbols only available for arm32, as that was what it looked like in the 3 separate dumps before that) and concluded that whatever is common/shared between them, also should exist similarly for arm64. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 1/3] crt: msvcrt20.def.in: Document different msvcrt20.dll versions
On Mon, 1 Apr 2024, Pali Rohár wrote: The original msvcrt20.dll version from Visual C++ 2.0 does not contain some symbols, which are present in the version from Visual C++ 2.1 Upgrade. Also Win32s version of msvcrt20.dll from Visual C++ 2.0 does not contain all symbols as full version. Follow up Visual C++ 2.2 Upgrade version have not introduced any new symbol. Windows OS system versions of msvcrt20.dll contains same set of symbols as full version from Visual C++ 2.1 Upgrade. --- mingw-w64-crt/lib32/msvcrt20.def.in | 109 +++- 1 file changed, 57 insertions(+), 52 deletions(-) Thanks, these 3 patches seemed reasonable, so I pushed them. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 1/3] crt: Add non-inline variant of UCRT _scprintf, _snprintf and _snscanf functions
On Sat, 30 Mar 2024, Pali Rohár wrote: On Monday 25 March 2024 13:59:49 LIU Hao wrote: 在 2024-03-24 23:17, Pali Rohár 写道: I see... The problem is that inline version of that function in stdio.h conflicts with non-inline version in ucrt__scprintf.c file. One option how to avoid this problem is to not include stdio.h into ucrt__scprintf.c file. Other option can be to remove inline version completely. Please propose an updated patch for that. In 'ucrt__snwprintf.c' there are some hacks around it. Thank you for help. In attachment is an updated version. I checked that it works on top of the current master branch (because original version of the change is 2 years old now) and that it works for cases when target application includes stdio.h header file and also when it does not include it. For changes like this, where we're adding non-inline functions for _scprintf, _snprintf and _snscanf, I would very much prefer if we'd also remove the inline form of these functions at the same time. Right now, in the current form, the non-inline version of these functions are almost dead code and untestable with normal, proper use of the headers. It'd only be possible to test it by compiling code with headers in non-UCRT mode and linking against an UCRT import library. So instead, I'd prefer to remove the inline form of these functions, for clarity and simplicity. Then all use of these functions in UCRT mode go through these non-inline functions, and we can be sure that they work as intended just by testing using these functions in any UCRT environment. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH v2] crt: Use rand_s in the mkstemp function
On Thu, 7 Mar 2024, LIU Hao wrote: 在 2024-03-06 17:09, Martin Storsjö 写道: From: Mateusz Mikuła (...) The changes in this patch were proposed by Josh Stone on Rust's Zulip server and I was asked to forward it. Co-Authored-By: Josh Stone Signed-off-by: Mateusz Mikuła Signed-off-by: Martin Storsjö --- mingw-w64-crt/misc/mkstemp.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) This patch looks good itself. Pushed now, thanks! // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH v2] crt: Use rand_s in the mkstemp function
From: Mateusz Mikuła
When using mkstemp, there is no guarantee nor expectation that the
caller has called srand() with an unique seed. Therefore, in practice,
many users of mkstemp run with the same seed (unseeded).
Normally, the implementation of mkstemp does handle collisions just
fine, by continuing iteration and trying another pseudorandom file
name, until finding a unique name. (If there are collisions and both
processes run unseeded, both will always try the same sequence though.)
However in some rare cases of collisions, _sopen can return an error,
setting errno to e.g. EACCES. In this case, our implementation of
mkstemp stops iterating and returns the error to the caller. (This is,
in general, the right decision; if the user does not have write
permission in the expected directory, we should abort, not keep retrying
infinitely.)
Use rand_s() to get properly unique random numbers here, without
relying on the caller seeding the random number generator.
Older versions of msvcrt.dll do lack rand_s, but in libmsvcrt-os.a,
we provide rand_s as a wrapper that tries to locate rand_s at runtime,
and tries to do a fallback implementation otherwise. If all the
fallbacks within our rand_s() wrapper fail, fall back on plain rand(),
which is no worse than what we had before.
The issue with collisions can be reproduced with these commands (run
them all in without long pauses):
for n in {1..15000}; do rm -f lib/libLLVMAVRAsmParser.a && \
ar qc lib/libLLVMAVRAsmParser.a
lib/Target/AVR/AsmParser/CMakeFiles/LLVMAVRAsmParser.dir/AVRAsmParser.cpp.obj
&& \
ranlib.exe lib/libLLVMAVRAsmParser.a; done &
for n in {1..15000}; do rm -f lib/libLLVMSparcCodeGen.a && \
ar qc lib/libLLVMSparcCodeGen.a
lib/Target/Sparc/CMakeFiles/LLVMSparcCodeGen.dir/*.obj && \
ranlib.exe lib/libLLVMSparcCodeGen.a; done
echo "done"
fg
Before the patch it will fail with an error: "ranlib.exe: could not
create temporary file whilst writing archive: no more archived files"
or "...: Permission denied".
The changes in this patch were proposed by Josh Stone on Rust's Zulip
server and I was asked to forward it.
Co-Authored-By: Josh Stone
Signed-off-by: Mateusz Mikuła
Signed-off-by: Martin Storsjö
---
mingw-w64-crt/misc/mkstemp.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/mingw-w64-crt/misc/mkstemp.c b/mingw-w64-crt/misc/mkstemp.c
index 6b327f2fc..3b6246540 100644
--- a/mingw-w64-crt/misc/mkstemp.c
+++ b/mingw-w64-crt/misc/mkstemp.c
@@ -1,3 +1,4 @@
+#define _CRT_RAND_S
#include
#include
#include
@@ -25,6 +26,7 @@
int __cdecl mkstemp (char *template_name)
{
int i, j, fd, len, index;
+unsigned int r;
/* These are the (62) characters used in temporary filenames. */
static const char letters[] =
"abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789";
@@ -45,7 +47,9 @@ int __cdecl mkstemp (char *template_name)
*/
for (i = 0; i >= 0; i++) {
for(j = index; j < len; j++) {
-template_name[j] = letters[rand () % 62];
+if (rand_s())
+r = rand();
+template_name[j] = letters[r % 62];
}
fd = _sopen(template_name,
_O_RDWR | _O_CREAT | _O_EXCL | _O_BINARY,
--
2.34.1
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] Use rand_s in mkstemp function
On Mon, 4 Mar 2024, Martin Storsjö wrote:
Looking closer at our mkstemp implementation, we have this loop:
/*
Like OpenBSD, mkstemp() will try at least 2 ** 31 combinations before
giving up.
*/
for (i = 0; i >= 0; i++) {
for(j = index; j < len; j++) {
template_name[j] = letters[rand () % 62];
}
fd = _sopen(template_name,
_O_RDWR | _O_CREAT | _O_EXCL | _O_BINARY,
_SH_DENYNO, _S_IREAD | _S_IWRITE);
if (fd != -1) return fd;
if (fd == -1 && errno != EEXIST) return -1;
}
This should retry an absolutely insane number of times, so as long as one
process finds a unique file name and stops iterating, the other parallel
process should also find a unique one soon after, one would expect.
So if this fails, it looks like something is fishy here; if we have this
clash, do we hit the "if (fd == -1 && errno != EEXIST) return -1;" case
directly on the first iteration?
I tried reproducing this myself. I was able to hit the error, but only
very very rarely (I only reproduced it twice while running these loops for
an hour or two)).
The loop does work as expected, normally - in most cases of collisions, we
do continue iterating. Only in a very very small fraction of cases, we end
up with errno set to something else than EEXIST, e.g. EACCES. And overall,
erroring out on EACCES is the right thing to do, otherwise we'd loop
(near) infinitely if trying to create a temp file in a directory without
write permission.
So that clarifies the mystery to me. And the suggested fix of using
rand_s() sounds good to me, but we should keep a fallback to rand().
I'll post a new patch with that behaviour implemented, and with a slightly
updated commit message.
// Martin
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] crt: Provide fcloseall as alias to _fcloseall
On Mon, 4 Mar 2024, LIU Hao wrote: 在 2024-03-04 16:03, Martin Storsjö 写道: MSVC does provide this function without an underscore prefix (via the oldnames library) just like a number of other functions. In mingw-w64 headers, we already provide a declaration of this function, just like many others, but it was missing from the import libraries. Provide it as an alias, just like we do for many other similar functions that only exist with a leading underscore in the runtime DLLs. Signed-off-by: Martin Storsjö --- mingw-w64-crt/def-include/msvcrt-common.def.in | 1 + mingw-w64-crt/lib-common/api-ms-win-crt-stdio-l1-1-0.def | 1 + 2 files changed, 2 insertions(+) This patch looks good to me. Thanks, pushed. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] Use rand_s in mkstemp function
On Mon, 4 Mar 2024, Martin Storsjö wrote:
Hi,
On Mon, 4 Mar 2024, Mateusz Mikuła wrote:
rand is not random enough and may lead to clashing temporary directories
with multiple parallel link processes as it was observed on Rust's CI.
It can be reproduced with these commands (run them all in without long
pauses):
for n in {1..15000}; do rm -f lib/libLLVMAVRAsmParser.a && \
ar qc lib/libLLVMAVRAsmParser.a
lib/Target/AVR/AsmParser/CMakeFiles/LLVMAVRAsmParser.dir/AVRAsmParser.cpp.obj
&& \
ranlib.exe lib/libLLVMAVRAsmParser.a; done &
for n in {1..15000}; do rm -f lib/libLLVMSparcCodeGen.a && \
ar qc lib/libLLVMSparcCodeGen.a
lib/Target/Sparc/CMakeFiles/LLVMSparcCodeGen.dir/*.obj && \
ranlib.exe lib/libLLVMSparcCodeGen.a; done
echo "done"
fg
Before the patch it will fail with an error: ranlib.exe: could not create
temporary file whilst writing archive: no more archived files.
Thanks, I've run into this issue occasionally when building LLVM on msys2 as
well, but I've failed to reproduce it when I've tried to look closer at it
(as I've missed the issue that one needs to build two archives at the same
time in order to trigger it).
If the issue is that the randomness clashes, shouldn't that be something
that, as part of the contract of mkstemp, the function should retry until it
finds a non-conflicting combination? But, thinking further, is the issue that
two processes end up trying the same sequence of pseudo random files, which
all then end up clashing, and mkstemp returns an error as it was unable to
find a unique file name? I guess that's plausible. In that case, I guess this
patch is fine (with Liu Hao's suggestion), as a way to reduce the risk of
running into this.
Looking closer at our mkstemp implementation, we have this loop:
/*
Like OpenBSD, mkstemp() will try at least 2 ** 31 combinations before
giving up.
*/
for (i = 0; i >= 0; i++) {
for(j = index; j < len; j++) {
template_name[j] = letters[rand () % 62];
}
fd = _sopen(template_name,
_O_RDWR | _O_CREAT | _O_EXCL | _O_BINARY,
_SH_DENYNO, _S_IREAD | _S_IWRITE);
if (fd != -1) return fd;
if (fd == -1 && errno != EEXIST) return -1;
}
This should retry an absolutely insane number of times, so as long as one
process finds a unique file name and stops iterating, the other parallel
process should also find a unique one soon after, one would expect.
So if this fails, it looks like something is fishy here; if we have this
clash, do we hit the "if (fd == -1 && errno != EEXIST) return -1;" case
directly on the first iteration?
(Separately, it looks like the loop relies on undefined behaviour, signed
wraparound, in order to exit the loop.)
// Martin
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH] crt: Provide fcloseall as alias to _fcloseall
MSVC does provide this function without an underscore prefix (via the oldnames library) just like a number of other functions. In mingw-w64 headers, we already provide a declaration of this function, just like many others, but it was missing from the import libraries. Provide it as an alias, just like we do for many other similar functions that only exist with a leading underscore in the runtime DLLs. Signed-off-by: Martin Storsjö --- mingw-w64-crt/def-include/msvcrt-common.def.in | 1 + mingw-w64-crt/lib-common/api-ms-win-crt-stdio-l1-1-0.def | 1 + 2 files changed, 2 insertions(+) diff --git a/mingw-w64-crt/def-include/msvcrt-common.def.in b/mingw-w64-crt/def-include/msvcrt-common.def.in index ac56a6e21..9728b5ab8 100644 --- a/mingw-w64-crt/def-include/msvcrt-common.def.in +++ b/mingw-w64-crt/def-include/msvcrt-common.def.in @@ -35,6 +35,7 @@ ADD_UNDERSCORE(execv) ADD_UNDERSCORE(execve) ADD_UNDERSCORE(execvp) ADD_UNDERSCORE(execvpe) +ADD_UNDERSCORE(fcloseall) ADD_UNDERSCORE(fcvt) ADD_UNDERSCORE(fdopen) ADD_UNDERSCORE(fgetchar) diff --git a/mingw-w64-crt/lib-common/api-ms-win-crt-stdio-l1-1-0.def b/mingw-w64-crt/lib-common/api-ms-win-crt-stdio-l1-1-0.def index d59859ced..cdfc2362b 100644 --- a/mingw-w64-crt/lib-common/api-ms-win-crt-stdio-l1-1-0.def +++ b/mingw-w64-crt/lib-common/api-ms-win-crt-stdio-l1-1-0.def @@ -39,6 +39,7 @@ _eof eof == _eof _fclose_nolock _fcloseall +fcloseall == _fcloseall _fflush_nolock _fgetc_nolock _fgetchar -- 2.34.1 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] crt: Fix comments in msvcrt-common.def.in
On Sun, 3 Mar 2024, Pali Rohár wrote: On Sunday 03 March 2024 23:38:57 Martin Storsjö wrote: On Sun, 3 Mar 2024, Pali Rohár wrote: Ok, do you need me to resend this patch? Or would you fix this one missing semicolon during applying patch? I can fix the missing semicolon. And... I do not know how to better write the commit message, so I would be happy if give me example of how to rephrase it. Does this sound like a good commit message? If it's ok with you, I can push it in that form: ---8<--- crt: Fix comments in msvcrt-common.def.in The ADD_UNDERSCORE macro adds an alias, without a leading underscore, for an existing export with a leading underscore. For some functions, we're not providing these aliases, e.g. because those symbols are defined by other means, e.g. in source files (such as CRT_fp10.c and CRT_fp8.c). This patch improves the style of those cases, which are listed as commented out instances of the ADD_UNDERSCORE macro. ---8<--- // Martin That is nice, I like it! Thank you very much. Pushed in that form, thanks! // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] Use rand_s in mkstemp function
Hi,
On Mon, 4 Mar 2024, Mateusz Mikuła wrote:
rand is not random enough and may lead to clashing temporary directories
with multiple parallel link processes as it was observed on Rust's CI.
It can be reproduced with these commands (run them all in without long pauses):
for n in {1..15000}; do rm -f lib/libLLVMAVRAsmParser.a && \
ar qc lib/libLLVMAVRAsmParser.a
lib/Target/AVR/AsmParser/CMakeFiles/LLVMAVRAsmParser.dir/AVRAsmParser.cpp.obj
&& \
ranlib.exe lib/libLLVMAVRAsmParser.a; done &
for n in {1..15000}; do rm -f lib/libLLVMSparcCodeGen.a && \
ar qc lib/libLLVMSparcCodeGen.a lib/Target/Sparc/CMakeFiles/LLVMSparcCodeGen.dir/*.obj
&& \
ranlib.exe lib/libLLVMSparcCodeGen.a; done
echo "done"
fg
Before the patch it will fail with an error: ranlib.exe: could not create
temporary file whilst writing archive: no more archived files.
Thanks, I've run into this issue occasionally when building LLVM on msys2
as well, but I've failed to reproduce it when I've tried to look closer at
it (as I've missed the issue that one needs to build two archives at the
same time in order to trigger it).
If the issue is that the randomness clashes, shouldn't that be something
that, as part of the contract of mkstemp, the function should retry until
it finds a non-conflicting combination? But, thinking further, is the
issue that two processes end up trying the same sequence of pseudo random
files, which all then end up clashing, and mkstemp returns an error as it
was unable to find a unique file name? I guess that's plausible. In that
case, I guess this patch is fine (with Liu Hao's suggestion), as a way to
reduce the risk of running into this.
// Martin
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] crt: Fix comments in msvcrt-common.def.in
On Sun, 3 Mar 2024, Pali Rohár wrote: Ok, do you need me to resend this patch? Or would you fix this one missing semicolon during applying patch? I can fix the missing semicolon. And... I do not know how to better write the commit message, so I would be happy if give me example of how to rephrase it. Does this sound like a good commit message? If it's ok with you, I can push it in that form: ---8<--- crt: Fix comments in msvcrt-common.def.in The ADD_UNDERSCORE macro adds an alias, without a leading underscore, for an existing export with a leading underscore. For some functions, we're not providing these aliases, e.g. because those symbols are defined by other means, e.g. in source files (such as CRT_fp10.c and CRT_fp8.c). This patch improves the style of those cases, which are listed as commented out instances of the ADD_UNDERSCORE macro. ---8<--- // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] crt: Define 32-bit time function aliases for all CRT libraries
On Wed, 28 Feb 2024, Martin Storsjö wrote: On Wed, 28 Feb 2024, Pali Rohár wrote: Header file time.h already redirects function call gmtime() to _gmtime32(). So if object file compiled with time.h is linked with e.g. libmsvcrt40.a import library then it is needed to add redirection from _gmtime32 symbol to gmtime symbol into libmsvcrt40.a library to ensure that application would use gmtime symbol, because msvcrt40.dll does not provide _gmtime32. Same applies for all other 32-bit time symbols. --- mingw-w64-crt/lib32/crtdll.def.in | 14 +- mingw-w64-crt/lib32/msvcr70.def.in | 11 +++ mingw-w64-crt/lib32/msvcr71.def.in | 11 +++ mingw-w64-crt/lib32/msvcrt10.def.in | 9 + mingw-w64-crt/lib32/msvcrt20.def.in | 11 +++ mingw-w64-crt/lib32/msvcrt40.def.in | 11 +++ 6 files changed, 62 insertions(+), 5 deletions(-) LGTM I pushed this, and the other patches I had OK'd now. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] headers: Move some macros about deprecated functions from 'strsafe.h' into 'dontuse.h'
On Fri, 1 Mar 2024, LIU Hao wrote: 在 2024-02-29 16:25, Martin Storsjö 写道: The functions within the DEPRECATE_SUPPORTED block in strsafe.h are not defined elsewhere, they are all inline functions within strsafe.h. So there is no way of having code that otherwise works, then you include strsafe.h and suddenly it no longer works. Kind of. Prior to this patch, including 'strsafe.h' then 'windows.h' will result in errors, even those functions aren't used in any way. So I suspect such code doesn't exist. Attached is an updated patch, with the last two paragraphs rephrased. LGTM, thanks! // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] headers: Move some macros about deprecated functions from 'strsafe.h' into 'dontuse.h'
On Thu, 29 Feb 2024, LIU Hao wrote: 在 2024-02-29 01:14, Martin Storsjö 写道: It would be much more understandable, if the message would start with some context like this: ---8<--- WinSDK's strsafe.h also tries to discourage users from calling a bunch of its internal functions. This is done in two different ways; if DEPRECATE_SUPPORTED is defined (it gets defined by winnt.h), the functions are marked deprecated via e.g. "#pragma deprecated(StringLengthWorkerA)". If that isn't defined, those symbols are redefined to a missing name instead, e.g. "#define StringLengthWorkerA StringLengthWorkerA_instead_use_StringCchLengthA_or_StringCbLengthA" This contradicts my understanding: I don't think that `DEPRECATE_SUPPORTED` is a macro that is to be defined by users. Its conditional definition in 'winnt.h' is protected by `DECLSPEC_DEPRECATED`, and if a user defines it on themselves, they will get warnings about redefinition. I did not imply that it is supposed to be defined by users, I just tried to explain the behaviour of WinSDK's strsafe.h, with respect to inclusion of other headers. As GCC doesn't support #pragma deprecated, our version doesn't use that, so we only redirect/rename uses of these functions if DEPRECATE_SUPPORTED isn't defined - to match the effect on the WinSDK headers (where the names are usable but gets warned about, if DEPRECATE_SUPPORTED is defined). ---8<--- That, IMO, is more understandable by people just looking at the patch in isolation, and/or looking at our headers. Alternatively, we could just skip adding this ifdef in this patch, as we don't have the alternative way of marking the deprecation - that would get the message across to the users even more clearly? There is a difference about these two approaches: `#pragma deprecated` effects warnings, while defining those names to non-exitent ones effects hard errors. That's true, there's a difference between warnings and hard errors - I understand that you want to mimic this aspect of the WinSDK headers. Including 'dontuse.h' and getting hard errors might be expected, but including 'strsafe.h' and getting accidental hard errors is probably unwanted. There's a bit of difference here. The dontuse.h header affects symbols defined in other headers, making sure that one does not use symbols that otherwise would be fine to use. The functions within the DEPRECATE_SUPPORTED block in strsafe.h are not defined elsewhere, they are all inline functions within strsafe.h. So there is no way of having code that otherwise works, then you include strsafe.h and suddenly it no longer works. That's why I think it might be fine to just keep the hard error defines for these functions, unconditionally as long as we don't have any #pragma deprecate anyway. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] crt: Fix comments in msvcrt-common.def.in
On Thu, 29 Feb 2024, Pali Rohár wrote:
On Wednesday 28 February 2024 23:24:25 Martin Storsjö wrote:
On Wed, 28 Feb 2024, Pali Rohár wrote:
All commented lines refers to non-underscore aliases for underscored
variant of functions. Aliases for some reasons are not prevent, e.g.
because some aliases are defined in other files (CRT_fp10.c and CRT_fp8.c).
I don't understand what the second sentence here is saying, can you rephrase
it?
Ah, now I see, with s/prevent/present/, the sentence is a bit more
understandable.
Ok, I will try to explain it a bit more. ADD_UNDERSCORE is a macro which
just adds a symbol alias. It does not export any new symbol.
#define ADD_UNDERSCORE(symbol) symbol == _ ## symbol
Symbol "fpreset" is already defined in CRT_fp10.c and CRT_fp8.c files as
an alias to the "_fpreset" symbol.
So ADD_UNDERSCORE(fpreset) should not be added into msvcrt-common.def.in
because same job is already done by __attribute__((alias("_fpreset"))).
Thanks, that's more understandable :-)
---
mingw-w64-crt/def-include/msvcrt-common.def.in | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
@@ -134,13 +135,13 @@ ADD_UNDERSCORE(y0)
ADD_UNDERSCORE(y1)
ADD_UNDERSCORE(yn)
ADD_UNDERSCORE(chgsign)
-;scalb
+ADD_UNDERSCORE(scalb)
This change here is, accidentally?, actually adding the alias even though it
was supposed to be commented out?
// Martin
Ah, it should not be there. My attempt was to cleanup comments without
any functional change. But all those parenthesis, semicolons and pluses
in diff make me hard to miss some accidental changes.
Yep. I'd be fine with the patch with the commit message typo fixed (or
with the more verbose version), and this typo here fixed as well.
// Martin
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] crt: Define 32-bit time function aliases for all CRT libraries
On Wed, 28 Feb 2024, Pali Rohár wrote: Header file time.h already redirects function call gmtime() to _gmtime32(). So if object file compiled with time.h is linked with e.g. libmsvcrt40.a import library then it is needed to add redirection from _gmtime32 symbol to gmtime symbol into libmsvcrt40.a library to ensure that application would use gmtime symbol, because msvcrt40.dll does not provide _gmtime32. Same applies for all other 32-bit time symbols. --- mingw-w64-crt/lib32/crtdll.def.in | 14 +- mingw-w64-crt/lib32/msvcr70.def.in | 11 +++ mingw-w64-crt/lib32/msvcr71.def.in | 11 +++ mingw-w64-crt/lib32/msvcrt10.def.in | 9 + mingw-w64-crt/lib32/msvcrt20.def.in | 11 +++ mingw-w64-crt/lib32/msvcrt40.def.in | 11 +++ 6 files changed, 62 insertions(+), 5 deletions(-) LGTM // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] crt: Fix comments in msvcrt-common.def.in
On Wed, 28 Feb 2024, Pali Rohár wrote: All commented lines refers to non-underscore aliases for underscored variant of functions. Aliases for some reasons are not prevent, e.g. because some aliases are defined in other files (CRT_fp10.c and CRT_fp8.c). I don't understand what the second sentence here is saying, can you rephrase it? --- mingw-w64-crt/def-include/msvcrt-common.def.in | 15 --- 1 file changed, 8 insertions(+), 7 deletions(-) @@ -134,13 +135,13 @@ ADD_UNDERSCORE(y0) ADD_UNDERSCORE(y1) ADD_UNDERSCORE(yn) ADD_UNDERSCORE(chgsign) -;scalb +ADD_UNDERSCORE(scalb) This change here is, accidentally?, actually adding the alias even though it was supposed to be commented out? // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] crt: Update crtdll.def.in
On Wed, 28 Feb 2024, Pali Rohár wrote: * Include C++ mangled symbols * Include Windows NT 3.51+ symbols * Extend comment about different versions * Update list of symbols which do not have prototypes yet --- mingw-w64-crt/lib32/crtdll.def.in | 152 ++ 1 file changed, 29 insertions(+), 123 deletions(-) LGTM // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
