Re: [Mingw-w64-public] [PATCH 2/7] crt: msvcr90d.def.in: Fix I386 symbol alias _wfindnext
在 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`. In the case of x86 stdcall, both `foo` and `bar` shall include an `@` suffix. * `foo == bar` (renaming) indicates that a function called `foo` exists in the DLL's source code, and it is exported as `bar`. `bar` may and may not contain an `@` suffix, as the use varies. [1] https://sourceware.org/binutils/docs/binutils/def-file-format.html -- Best regards, LIU Hao OpenPGP_signature.asc Description: OpenPGP digital signature ___ 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: Add tcpxcv.h
在 2024-04-23 15:42, Biswapriyo Nath 写道: From fe72cdf89cd2d583c3fa4c43406fc08777bc1fe5 Mon Sep 17 00:00:00 2001 From: Biswapriyo Nath Date: Tue, 23 Apr 2024 07:41:17 + Subject: [PATCH] headers: Add tcpxcv.h Fixeshttps://github.com/mingw-w64/mingw-w64/issues/46 Signed-off-by: Biswapriyo Nath --- mingw-w64-headers/include/tcpxcv.h | 92 ++ 1 file changed, 92 insertions(+) create mode 100644 mingw-w64-headers/include/tcpxcv.h Thanks for the patch. Pushed to master now. -- Best regards, LIU Hao OpenPGP_signature.asc Description: OpenPGP digital signature ___ 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: add a .gitignore
在 2024-04-25 20:36, Antonin Décimo 写道: Do you wish to create a separate repository for winpthreads, and commit .gitignore there? We're maintaining a separate repository at https://github.com/ocaml/winpthreads, with instructions on how to embed the subtree as a submodule in the ocaml sources at https://github.com/ocaml/ocaml/blob/trunk/HACKING.adoc#the-winpthreads-library-for-the-msvc-port. The subtree with these instructions allow us to keep the same commit id as the upstream in our winpthreads submodule. Fancy. Wow, haven't heard of `git subtree` at all! Thanks for the idea. Pushed to master now. May I ask: it doesn't seem that winpthreads, or other mingw-w64-libraries are tied to a specific commit of mingw. Maybe they don't need to be in the mingw-w64 "monorepo"? I understand it wouldn't be easy if they're used for instance to build mingw. This has been the case since SVN days. One advantage of SVN over Git is that it allows checking out subdirectories, so this was not an issue. Not sure about the precise reason though. -- Best regards, LIU Hao OpenPGP_signature.asc Description: OpenPGP digital signature ___ 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: add a .gitignore
在 2024-04-24 21:43, Antonin Décimo 写道: This helps when vendoring winpthreads as a subtree. --- I've just copied the root .gitignore. Works as expected. mingw-w64-libraries/winpthreads/.gitignore | 41 ++ 1 file changed, 41 insertions(+) create mode 100644 mingw-w64-libraries/winpthreads/.gitignore Do you wish to create a separate repository for winpthreads, and commit .gitigoore there? In mingw-w64 the top-level .gitignore applies and there is no need to maintain a same one in a subdirectory. If you would like to fork a separate directory, you can just copy the top-level one. (BTW I don't think it's necessary; you can fork mingw-w64 as a whole, and it makes rebasing automatic and easier.) -- Best regards, LIU Hao OpenPGP_signature.asc Description: OpenPGP digital signature ___ 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
在 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.
--
Best regards,
LIU Hao
OpenPGP_signature.asc
Description: OpenPGP digital signature
___
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
在 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. If there's no problems using _ReadWriteBarrier, it seems like the easiest solution. I'd suggest moving to C11 atomic_thread_fence [1], but MSVC likely misses support… Strangely that MSVC has only gained C11 atomic recently, and requires `/std:c11 /experimental:c11atomics`. So it yet results in more complexity which I think we had better avoid: #if defined __GNUC__ || defined __clang__ /* GCC or Clang-CL */ # define __pthread_MemoryBarrier() \ __sync_synchronize() /* __atomic_thread_fence(__ATOMIC_SEQ_CST) */ #elif defined __cplusplus && (__cplusplus >= 201103L) /* C++11 */ # include # define __pthread_MemoryBarrier() \ ::std::atomic_thread_fence(::std::memory_order_seq_cst) #else /* C11 */ # include # define __pthread_MemoryBarrier() \ atomic_thread_fence(memory_order_seq_cst) #endif -- Best regards, LIU Hao OpenPGP_signature.asc Description: OpenPGP digital signature ___ 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
在 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. -- Best regards, LIU Hao OpenPGP_signature.asc Description: OpenPGP digital signature ___ 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
在 2024-04-19 16:00, LIU Hao 写道: The conversion from `char**` to `const char* const*` is only implicit in C++, and not in C. The POSIX prototypes have only one `const` [1]. The Microsoft variants do have double `const` [2], so I think the proposed patch may be acceptable, as long as users have been aware of that. My second thought is that GCC 14 (not branched yet, but available from https://gcc.godbolt.org/z/E9EnYTG39) starts to reject such conversions. Given that these names are POSIX, I'd prefer we follow POSIX and leave them alone. BTW, I would like to hear about the issues that they are causing. -- Best regards, LIU Hao OpenPGP_signature.asc Description: OpenPGP digital signature ___ 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
在 2024-04-19 15:37, Martin Storsjö 写道:
- _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.
The conversion from `char**` to `const char* const*` is only implicit in C++, and not in C. The
POSIX prototypes have only one `const` [1].
The Microsoft variants do have double `const` [2], so I think the proposed patch may be acceptable,
as long as users have been aware of that.
[1] https://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html
[2]
https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/execve-wexecve?view=msvc-170
$ cat test.c
void use(const char* const* pp);
void pass(char** pp) { use(pp); }
$ gcc -fsyntax-only -W{all,extra,pedantic} test.c
test.c: In function ‘pass’:
test.c:2:28: warning: passing argument 1 of ‘use’ from incompatible pointer type
[-Wincompatible-pointer-types]
2 | void pass(char** pp) { use(pp); }
|^~
||
|char **
test.c:1:29: note: expected ‘const char * const*’ but argument is of type
‘char **’
1 | void use(const char* const* pp);
| ~~~^~
--
Best regards,
LIU Hao
OpenPGP_signature.asc
Description: OpenPGP digital signature
___
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
在 2024-04-17 05:08, Martin Storsjö 写道: Thanks, I think this one looks reasonable. Thanks. Pushed now. -- Best regards, LIU Hao OpenPGP_signature.asc Description: OpenPGP digital signature ___ 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
在 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.
--
Best regards,
LIU Hao
From cf60a31beaccfd85c7bde845b5003e402450b98b Mon Sep 17 00:00:00 2001
From: LIU Hao
Date: Tue, 16 Apr 2024 22:13:07 +0800
Subject: [PATCH] crt: Fix some symbols with duplicate stdcall suffixes
Some of these functions, such as `ConvertAtJobsToTasks`, are exported with both
undecorated and decorated names, respectively, `ConvertAtJobsToTasks` and
`_ConvertAtJobsToTasks@0`. The decorated names are almost useless for C code
anyway and are removed.
Some other stdcall functions, such as `__fls_getvalue`, are only exported with
decorated names. A new macro `DECORATED_EXPORT()` is introduced for them.
This fixes errors like
#include
#include
/* This was `__stdcall` in X3DAUDIO1_2.DLL, and changed to `__cdecl` later.
*/
__declspec(dllimport) void __stdcall X3DAudioCalculate(void*, void*, void*,
UINT, void*);
int main(void)
{
printf("X3DAudioCalculate = %p\n", (void*)(INT_PTR) X3DAudioCalculate);
}
which used to result in
test.c:(.text+0xf): undefined reference to `_imp__X3DAudioCalculate@20'
Signed-off-by: LIU Hao
---
mingw-w64-crt/def-include/msvcrt-common.def.in | 3 +++
mingw-w64-crt/lib32/mstask.def | 13 -
mingw-w64-crt/lib32/msvcr100.def.in| 4 ++--
mingw-w64-crt/lib32/msvcr90.def.in | 4 ++--
mingw-w64-crt/lib32/msvcr90d.def.in| 4 ++--
mingw-w64-crt/lib32/msvcrt20.def.in| 2 +-
mingw-w64-crt/lib32/t2embed.def| 11 ---
mingw-w64-crt/lib32/usbd.def | 12 +++-
mingw-w64-crt/lib32/x3daudio1_2.def| 6 ++
9 files changed, 15 insertions(+), 44 deletions(-)
diff --git a/mingw-w64-crt/def-include/msvcrt-common.def.in
b/mingw-w64-crt/def-include/msvcrt-common.def.in
index 9728b5ab8..975df5da9 100644
--- a/mingw-w64-crt/def-include/msvcrt-common.def.in
+++ b/mingw-w64-crt/def-include/msvcrt-common.def.in
@@ -3,6 +3,9 @@
#define ADD_UNDERSCORE(symbol) symbol == _ ## symbol
#define ADD_DOUBLE_UNDERSCORE(symbol) symbol == __ ## symbol
+// for __cdecl and __stdcall only
+#define DECORATED_EXPORT(symbol) symbol == _ ## symbol
+
ADD_DOUBLE_UNDERSCORE(iscsymf)
ADD_DOUBLE_UNDERSCORE(iscsym)
ADD_DOUBLE_UNDERSCORE(isascii)
diff --git a/mingw-w64-crt/lib32/mstask.def b/mingw-w64-crt/lib32/mstask.def
index 2cc5298e7..ba8f873a0 100644
--- a/mingw-w64-crt/lib32/mstask.def
+++ b/mingw-w64-crt/lib32/mstask.def
@@ -18,16 +18,3 @@ SAGetNSAccountInformation@12
SASetAccountInformation@20
SASetNSAccountInformation@12
SetNetScheduleAccountInformation@12
-_ConvertAtJobsToTasks@0@0
-_DllCanUnloadNow@0@0
-_DllGetClassObject@12@12
-_GetNetScheduleAccountInformation@12@12
-_NetrJobAdd@12@12
-_NetrJobDel@12@12
-_NetrJobEnum@20@20
-_NetrJobGetInfo@12@12
-_SAGetAccountInformation@16@16
-_SAGetNSAccountInformation@12@12
-_SASetAccountInformation@20@20
-_SASetNSAccountInformation@12@12
-_SetNetScheduleAccountInformation@12@12
diff --git a/mingw-w64-crt/lib32/msvcr100.def.in
b/mingw-w64-crt/lib32/msvcr100.def.in
index e2e0e18c7..00d99124b 100644
--- a/mingw-w64-crt/lib32/msvcr100.def.in
+++ b/mingw-w64-crt/lib32/msvcr100.def.in
@@ -626,8 +626,8 @@ __daylight
__dllonexit
__doserrno
__dstbias
-___fls_getvalue@4@4
-___fls_setvalue@8@8
+DECORATED_EXPORT(__fls_getvalue@4)
+DECORATED_EXPORT(__fls_setvalue@8)
__fpecode
__free_locale
__get_current_locale
diff --git a/mingw-w64-crt/lib32/msvcr90.def.in
b/mingw-w64-crt/lib32/msvcr90.def.in
index 4424adfe5..c5a70d3e9 100644
--- a/mingw-w64-crt/lib32/msvcr90.def.in
+++ b/mingw-w64-crt/lib32/msvcr90.def.in
@@ -230,8 +230,8 @@ __daylight
__dllonexit
__doserrno
__dstbias
-___fls_getvalue@4@4
-___fls_setvalue@8@8
+DECORATED_EXPORT(__fls_getvalue@4)
+DECORATED_EXPORT(__fls_setvalue@8)
__fpecode
__free_locale
__get_app_type
diff --git a/mingw-w64-crt/lib32/msvcr90d.def.in
b/mingw-w64-crt/lib32/msvcr90d.def.in
index 2835301f0..ba7dffa1c 100644
--- a/mingw-w64-crt/lib32/msvcr90d.def.in
+++ b/mingw-w64-crt/lib32/msvcr90d.def.in
@@ -270,8 +270,8 @@ __daylight
__dllonexit
__doserrno
__dstbias
-___fls_getvalue@4@4
-___fls_setvalue@8@8
+DECORATED_EXPORT(__fls_getvalue@4)
+DECORATED_EXPORT(__fls_setvalue@8)
__fpecode
__free_locale
__get_app_type
diff --git a/mingw-w64-crt/lib32/msvcrt20.def.in
b/mingw-w64-crt/lib32/msvcrt20.def.in
index d2702db90..1ac4d4701 100644
--- a/mingw-w64-crt/lib32/msvcrt20.def.in
+++ b/mingw-w64-crt/lib32/msvcrt20.def.in
Re: [Mingw-w64-public] [PATCH 2/2] crt: Fix some symbols with duplicate stdcall suffixes
在 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. 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. -- Best regards, LIU Hao OpenPGP_signature.asc Description: OpenPGP digital signature ___ 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
在 2024-04-16 05:57, Pali Rohár 写道: There is one another thing suspicious here. Function takes two float arguments, but one argument is passed via floating-point register and another via stack. Yes it looks like the case. From what I found on internet, it looks like that stdcall calling convention never use floating-point registers for passing arguments. So this function cannot be real stdcall. For x86, floating-point arguments are always passed on stack except with `__vectorcall`. This function looks like kinda modified `__fastcall` ones; it does not look like a public calling convention. 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? 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. -- Best regards, LIU Hao OpenPGP_signature.asc Description: OpenPGP digital signature ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH 2/2] crt: Fix some symbols with duplicate stdcall suffixes
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'.
3. 'lib32/usbd.def' was regenerated from USBD.SYS from Windows XP 32-bit.
--
Best regards,
LIU Hao
From 357c980c8a7b472a8e115b7af942531be915242b Mon Sep 17 00:00:00 2001
From: LIU Hao
Date: Mon, 15 Apr 2024 23:08:08 +0800
Subject: [PATCH 2/2] crt: Fix some symbols with duplicate stdcall suffixes
Some of these functions, such as `ConvertAtJobsToTasks`, are exported with both
undecorated and decorated names, respectively, `ConvertAtJobsToTasks` and
`_ConvertAtJobsToTasks@0`. The decorated names are almost useless for C code
anyway and are removed.
Some other stdcall functions, such as `__fls_getvalue`, are only exported with
decorated names. We have the macro `ADD_UNDERSCORE()` for them.
This fixes errors like
#include
#include
/* This was `__stdcall` in X3DAUDIO1_2.DLL, and changed to `__cdecl` later.
*/
__declspec(dllimport) void __stdcall X3DAudioCalculate(void*, void*, void*,
UINT, void*);
int main(void)
{
printf("X3DAudioCalculate = %p\n", (void*)(INT_PTR) X3DAudioCalculate);
}
which used to result in
test.c:(.text+0xf): undefined reference to `_imp__X3DAudioCalculate@20'
Signed-off-by: LIU Hao
---
mingw-w64-crt/def-include/func.def.in | 3 +++
mingw-w64-crt/def-include/msvcrt-common.def.in | 3 ---
mingw-w64-crt/lib32/mstask.def | 13 -
mingw-w64-crt/lib32/msvcr100.def.in| 4 ++--
mingw-w64-crt/lib32/msvcr90.def.in | 4 ++--
mingw-w64-crt/lib32/msvcr90d.def.in| 4 ++--
mingw-w64-crt/lib32/msvcrt20.def.in| 2 +-
mingw-w64-crt/lib32/t2embed.def| 11 ---
mingw-w64-crt/lib32/usbd.def | 12 +++-
mingw-w64-crt/lib32/x3daudio1_2.def| 11 ---
mingw-w64-crt/lib32/x3daudio1_2.def.in | 6 ++
11 files changed, 19 insertions(+), 54 deletions(-)
delete mode 100644 mingw-w64-crt/lib32/x3daudio1_2.def
create mode 100644 mingw-w64-crt/lib32/x3daudio1_2.def.in
diff --git a/mingw-w64-crt/def-include/func.def.in
b/mingw-w64-crt/def-include/func.def.in
index 58cc36d86..c67b6efe1 100644
--- a/mingw-w64-crt/def-include/func.def.in
+++ b/mingw-w64-crt/def-include/func.def.in
@@ -55,3 +55,6 @@
#ifndef F_NON_I386
#define F_NON_I386(x)
#endif
+
+#define ADD_UNDERSCORE(symbol) symbol == _ ## symbol
+#define ADD_DOUBLE_UNDERSCORE(symbol) symbol == __ ## symbol
diff --git a/mingw-w64-crt/def-include/msvcrt-common.def.in
b/mingw-w64-crt/def-include/msvcrt-common.def.in
index 9728b5ab8..80ce5e9fe 100644
--- a/mingw-w64-crt/def-include/msvcrt-common.def.in
+++ b/mingw-w64-crt/def-include/msvcrt-common.def.in
@@ -1,8 +1,5 @@
#include "func.def.in"
-#define ADD_UNDERSCORE(symbol) symbol == _ ## symbol
-#define ADD_DOUBLE_UNDERSCORE(symbol) symbol == __ ## symbol
-
ADD_DOUBLE_UNDERSCORE(iscsymf)
ADD_DOUBLE_UNDERSCORE(iscsym)
ADD_DOUBLE_UNDERSCORE(isascii)
diff --git a/mingw-w64-crt/lib32/mstask.def b/mingw-w64-crt/lib32/mstask.def
index 2cc5298e7..ba8f873a0 100644
--- a/mingw-w64-crt/lib32/mstask.def
+++ b/mingw-w64-crt/lib32/mstask.def
@@ -18,16 +18,3 @@ SAGetNSAccountInformation@12
SASetAccountInformation@20
SASetNSAccountInformation@12
SetNetScheduleAccountInformation@12
-_ConvertAtJobsToTasks@0@0
-_DllCanUnloadNow@0@0
-_DllGetClassObject@12@12
-_GetNetScheduleAccountInformation@12@12
-_NetrJobAdd@12@12
-_NetrJobDel@12@12
-_NetrJobEnum@20@20
-_NetrJobGetInfo@12@12
-_SAGetAccountInformation@16@16
-_SAGetNSAccountInformation@12@12
-_SASetAccountInformation@20@20
-_SASetNSAccountInformation@12@12
-_SetNetScheduleAccountInformation@12@12
diff --git a/mingw-w64-crt/lib32/msvcr100.def.in
b/mingw-w64-crt/lib32/msvcr100.def.in
index e2e0e18c7..b802b288c 100644
--- a/mingw-w64-crt/lib32/msvcr100.def.in
+++ b/mingw-w64-crt/lib32/msvcr100.def.in
@@ -626,8 +626,8 @@ __daylight
__dllonexit
__doserrno
__dstbias
-___fls_getvalue@4@4
-___fls_setvalue@8@8
+ADD_UNDERSCORE(__fls_getvalue@4)
+ADD_UNDERSCORE(__fls_setvalue@8)
__fpecode
__free_locale
__get_current_locale
diff --git a/mingw-w64-crt/lib32/msvcr90.def.in
b/mingw-w64-crt/lib32/msvcr90.def.in
index 4424adfe5..1bc161a5f 100644
--- a/mingw-w64-crt/lib32/msvcr90.def.in
+++ b/mingw-w64-crt/lib32/msvcr90.def.in
@@ -230,8 +230,8 @@ __daylight
__dllonexit
__doserrno
__dstbias
-___fls_getvalue@4@4
-___fls_setvalue@8@8
+ADD_UNDERSCORE(__fls_getvalue@4)
+ADD_UNDERSCORE(__fls_setvalue@8)
__fpecode
__free_locale
__get_app_type
diff --git a/mingw-w64-crt/lib32/msvcr90d.def.in
b/mingw-w64-crt/lib32/msvcr90d.def.in
index 2835301
[Mingw-w64-public] [PATCH 1/2] crt/xaudio2_9: Fix export names of `X3DAudioCalculate` and `X3DAudioInitialize`
--
Best regards,
LIU Hao
From b8b2b024cde9fd66b2280cba7ed995771882b366 Mon Sep 17 00:00:00 2001
From: LIU Hao
Date: Mon, 15 Apr 2024 23:30:50 +0800
Subject: [PATCH 1/2] crt/xaudio2_9: Fix export names of `X3DAudioCalculate`
and `X3DAudioInitialize`
These are not `__stdcall` functions, but `__cdecl` ones.
N.B. it was `__stdcall` in X3DAUDIO1_2.
Signed-off-by: LIU Hao
---
mingw-w64-crt/lib32/xaudio2_9.def | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mingw-w64-crt/lib32/xaudio2_9.def
b/mingw-w64-crt/lib32/xaudio2_9.def
index b283fab53..610271dc5 100644
--- a/mingw-w64-crt/lib32/xaudio2_9.def
+++ b/mingw-w64-crt/lib32/xaudio2_9.def
@@ -9,8 +9,8 @@ XAudio2Create@12
CreateAudioReverb@4
CreateAudioVolumeMeter@4
CreateFX@0
-X3DAudioCalculate@0
-X3DAudioInitialize@0
+X3DAudioCalculate
+X3DAudioInitialize
CreateAudioReverbV2_8@4
XAudio2CreateV2_9@12
XAudio2CreateWithVersionInfo@16
--
2.44.0
From 357c980c8a7b472a8e115b7af942531be915242b Mon Sep 17 00:00:00 2001
From: LIU Hao
Date: Mon, 15 Apr 2024 23:08:08 +0800
Subject: [PATCH 2/2] crt: Fix some symbols with duplicate stdcall suffixes
Some of these functions, such as `ConvertAtJobsToTasks`, are exported with both
undecorated and decorated names, respectively, `ConvertAtJobsToTasks` and
`_ConvertAtJobsToTasks@0`. The decorated names are almost useless for C code
anyway and are removed.
Some other stdcall functions, such as `__fls_getvalue`, are only exported with
decorated names. We have the macro `ADD_UNDERSCORE()` for them.
This fixes errors like
#include
#include
/* This was `__stdcall` in X3DAUDIO1_2.DLL, and changed to `__cdecl` later.
*/
__declspec(dllimport) void __stdcall X3DAudioCalculate(void*, void*, void*,
UINT, void*);
int main(void)
{
printf("X3DAudioCalculate = %p\n", (void*)(INT_PTR) X3DAudioCalculate);
}
which used to result in
test.c:(.text+0xf): undefined reference to `_imp__X3DAudioCalculate@20'
Signed-off-by: LIU Hao
---
mingw-w64-crt/def-include/func.def.in | 3 +++
mingw-w64-crt/def-include/msvcrt-common.def.in | 3 ---
mingw-w64-crt/lib32/mstask.def | 13 -
mingw-w64-crt/lib32/msvcr100.def.in| 4 ++--
mingw-w64-crt/lib32/msvcr90.def.in | 4 ++--
mingw-w64-crt/lib32/msvcr90d.def.in| 4 ++--
mingw-w64-crt/lib32/msvcrt20.def.in| 2 +-
mingw-w64-crt/lib32/t2embed.def| 11 ---
mingw-w64-crt/lib32/usbd.def | 12 +++-
mingw-w64-crt/lib32/x3daudio1_2.def| 11 ---
mingw-w64-crt/lib32/x3daudio1_2.def.in | 6 ++
11 files changed, 19 insertions(+), 54 deletions(-)
delete mode 100644 mingw-w64-crt/lib32/x3daudio1_2.def
create mode 100644 mingw-w64-crt/lib32/x3daudio1_2.def.in
diff --git a/mingw-w64-crt/def-include/func.def.in
b/mingw-w64-crt/def-include/func.def.in
index 58cc36d86..c67b6efe1 100644
--- a/mingw-w64-crt/def-include/func.def.in
+++ b/mingw-w64-crt/def-include/func.def.in
@@ -55,3 +55,6 @@
#ifndef F_NON_I386
#define F_NON_I386(x)
#endif
+
+#define ADD_UNDERSCORE(symbol) symbol == _ ## symbol
+#define ADD_DOUBLE_UNDERSCORE(symbol) symbol == __ ## symbol
diff --git a/mingw-w64-crt/def-include/msvcrt-common.def.in
b/mingw-w64-crt/def-include/msvcrt-common.def.in
index 9728b5ab8..80ce5e9fe 100644
--- a/mingw-w64-crt/def-include/msvcrt-common.def.in
+++ b/mingw-w64-crt/def-include/msvcrt-common.def.in
@@ -1,8 +1,5 @@
#include "func.def.in"
-#define ADD_UNDERSCORE(symbol) symbol == _ ## symbol
-#define ADD_DOUBLE_UNDERSCORE(symbol) symbol == __ ## symbol
-
ADD_DOUBLE_UNDERSCORE(iscsymf)
ADD_DOUBLE_UNDERSCORE(iscsym)
ADD_DOUBLE_UNDERSCORE(isascii)
diff --git a/mingw-w64-crt/lib32/mstask.def b/mingw-w64-crt/lib32/mstask.def
index 2cc5298e7..ba8f873a0 100644
--- a/mingw-w64-crt/lib32/mstask.def
+++ b/mingw-w64-crt/lib32/mstask.def
@@ -18,16 +18,3 @@ SAGetNSAccountInformation@12
SASetAccountInformation@20
SASetNSAccountInformation@12
SetNetScheduleAccountInformation@12
-_ConvertAtJobsToTasks@0@0
-_DllCanUnloadNow@0@0
-_DllGetClassObject@12@12
-_GetNetScheduleAccountInformation@12@12
-_NetrJobAdd@12@12
-_NetrJobDel@12@12
-_NetrJobEnum@20@20
-_NetrJobGetInfo@12@12
-_SAGetAccountInformation@16@16
-_SAGetNSAccountInformation@12@12
-_SASetAccountInformation@20@20
-_SASetNSAccountInformation@12@12
-_SetNetScheduleAccountInformation@12@12
diff --git a/mingw-w64-crt/lib32/msvcr100.def.in
b/mingw-w64-crt/lib32/msvcr100.def.in
index e2e0e18c7..b802b288c 100644
--- a/mingw-w64-crt/lib32/msvcr100.def.in
+++ b/mingw-w64-crt/lib32/msvcr100.def.in
@@ -626,8 +626,8 @@ __daylight
__dllonexit
__doserrno
__dstbias
-___fls_getvalue@4@4
-___fls_setvalue@8@8
+ADD_UNDERSCORE(__fls_getvalue@4)
+ADD_UNDERSCORE(__fls_setvalue@8)
__fpecode
__free_locale
__get_current_locale
diff --git a/mingw-w64-crt/lib32/msvcr90.def.in
b/mingw-w64-crt/lib32/msvcr90.def.in
index
Re: [Mingw-w64-public] [PATCH] crt: msvcr70.def.in: Add missing @SIZE suffixes and __CxxCallUnwindVecDtor
在 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. -- Best regards, LIU Hao OpenPGP_signature.asc Description: OpenPGP digital signature ___ 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 _swprintf/_vswprintf symbol aliases
在 2024-04-09 02:02, Pali Rohár 写道: Symbols _swprintf and _vswprintf were added in Windows Vista and have same meaning as symbols without leading underscore in msvcrt.dll. These symbols (both with and without leading underscore) differs from C99 variant as they do not take maxlen parameter. For compatibility with pre-Vista systems, which are x86-only, define _swprintf and _vswprintf symbols on I386 and X64 as aliases to swprintf and vswprintf. --- mingw-w64-crt/lib-common/msvcrt.def.in | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) This change looks good to me, so I pushed this. A little suggestion: If I was to import these functions, I would not add `swprintf` due to the inconsistency. For example, MSVCR120.DLL does not export `swprintf`, but only `_swprintf` and two C++ overloads; C++ names are mangled so they can never match each other. Maybe it's possible to add `swprintf` as an alias to the C99 one..? -- Best regards, LIU Hao OpenPGP_signature.asc Description: OpenPGP digital signature ___ 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] add PATHCCH_ENSURE_IS_EXTENDED_LENGTH_PATH to pathcch.h
在 2024-04-09 02:04, Oleg Tolmatcev 写道: Would the attached patch look good to you? Yes it looks good. Thank you. Thanks for the feedback. Pushed now. -- Best regards, LIU Hao OpenPGP_signature.asc Description: OpenPGP digital signature ___ 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] add PATHCCH_ENSURE_IS_EXTENDED_LENGTH_PATH to pathcch.h
在 2024-04-06 18:48, Oleg Tolmatcev 写道:
Hello,
this is needed by PCSX2.
Would the attached patch look good to you?
--
Best regards,
LIU Hao
From 52d6399f66c73a779f9b59391db3d59d98864e36 Mon Sep 17 00:00:00 2001
From: LIU Hao
Date: Mon, 8 Apr 2024 22:22:39 +0800
Subject: [PATCH] headers/pathcch: Add definition of `PATHCCH_OPTIONS`
Signed-off-by: LIU Hao
---
mingw-w64-headers/include/pathcch.h | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/mingw-w64-headers/include/pathcch.h
b/mingw-w64-headers/include/pathcch.h
index 3b0263634..62011fd1c 100644
--- a/mingw-w64-headers/include/pathcch.h
+++ b/mingw-w64-headers/include/pathcch.h
@@ -17,9 +17,20 @@ extern "C" {
#define VOLUME_PREFIX L"?\\Volume"
#define VOLUME_PREFIX_LEN (ARRAYSIZE (VOLUME_PREFIX) - 1)
-#define PATHCCH_ALLOW_LONG_PATHS 0x0001
#define PATHCCH_MAX_CCH 0x8000
+typedef enum PATHCCH_OPTIONS {
+ PATHCCH_NONE = 0x0,
+ PATHCCH_ALLOW_LONG_PATHS = 0x01,
+ PATHCCH_FORCE_ENABLE_LONG_NAME_PROCESS = 0x02,
+ PATHCCH_FORCE_DISABLE_LONG_NAME_PROCESS = 0x04,
+ PATHCCH_DO_NOT_NORMALIZE_SEGMENTS = 0x08,
+ PATHCCH_ENSURE_IS_EXTENDED_LENGTH_PATH = 0x10,
+ PATHCCH_ENSURE_TRAILING_SLASH = 0x020,
+ PATHCCH_CANONICALIZE_SLASHES = 0x040
+} PATHCCH_OPTIONS;
+DEFINE_ENUM_FLAG_OPERATORS(PATHCCH_OPTIONS)
+
WINPATHCCHAPI HRESULT APIENTRY PathAllocCombine (PCWSTR pszPathIn, PCWSTR
pszMore, unsigned long dwFlags, PWSTR *ppszPathOut);
WINPATHCCHAPI HRESULT APIENTRY PathAllocCanonicalize (PCWSTR pszPathIn,
unsigned long dwFlags, PWSTR *ppszPathOut);
WINPATHCCHAPI HRESULT APIENTRY PathCchAddBackslash (PWSTR pszPath, size_t
cchPath);
--
2.44.0
OpenPGP_signature.asc
Description: OpenPGP digital signature
___
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: Do not depend on _strtoi64/_strtoui64 symbols for I386 msvcrt.dll
在 2024-04-06 06:19, Pali Rohár 写道: Commit c52f1eb09901e038ceb7012730e7cf3395d65a78 incorectly stated that _strtoi64 and _strtoui64 symbols are available since the first release of msvcrt.dll library (part of MS Visual C++ 4.2). But only the symbol _atoi64 mentioned in that commit is available since the first msvcrt.dll release. Symbols _strtoi64 and _strtoui64 (as can be now seen in msvcrt.def.in comments) were introduced in Windows XP version of msvcrt.dll. So for I386 msvcrt.dll builds, use mingw-w64 implementation of _strtoi64 and _strtoui64 functions, like it was before that mentioned commit. The mentioned commit broke support for Windows NT 4.0 and Windows 2000 as msvcrt!_strtoi64 and msvcrt!_strtoui64 symbols are not available on these systems. This issue was reported by Marius Negruțiu into mingw-w64 bug tracker: https://sourceforge.net/p/mingw-w64/bugs/966/ --- mingw-w64-crt/Makefile.am | 2 ++ mingw-w64-crt/lib-common/msvcrt.def.in | 12 ++-- 2 files changed, 8 insertions(+), 6 deletions(-) Thanks for the patch. looks good to me, too. Pushed to master now. -- Best regards, LIU Hao OpenPGP_signature.asc Description: OpenPGP digital signature ___ 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: Cleanup _scprintf/_vscprintf for non-msvcrtos builds
在 2024-04-08 00:24, Pali Rohár 写道: For non-msvcrtos builds are global variables __MINGW_IMP_SYMBOL(_scprintf) __MINGW_IMP_SYMBOL(_vscprintf) not changing, they are constant. So define _scprintf and _vscprintf functions as direct alias to emu_scprintf and emu_vscprintf functions instead of via indirect unconditional jump or function call. This also simplifies _scprintf definition for non-msvcrtos builds as it reduces usage of inline assembly code. There is no change for msvcrtos build. --- mingw-w64-crt/stdio/_scprintf.c | 13 ++--- mingw-w64-crt/stdio/_vscprintf.c | 7 --- 2 files changed, 6 insertions(+), 14 deletions(-) These three patches about _scprintf look good to me. Pushed to master now. Thanks. -- Best regards, LIU Hao OpenPGP_signature.asc Description: OpenPGP digital signature ___ 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] add PATHCCH_ENSURE_IS_EXTENDED_LENGTH_PATH to pathcch.h
在 2024-04-06 18:48, Oleg Tolmatcev 写道: Hello, this is needed by PCSX2. Thanks for the patch. For this change, I suggest we add all `PATHCCH_*` constants, and change them to enumerators as in Windows 10 SDK. -- Best regards, LIU Hao OpenPGP_signature.asc Description: OpenPGP digital signature ___ 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
在 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. -- Best regards, LIU Hao OpenPGP_signature.asc Description: OpenPGP digital signature ___ 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] Fix UB in mkstemp retry loop
在 2024-03-23 06:36, Mateusz Mikuła 写道: Signed-off-by: Mateusz Mikuła --- mingw-w64-crt/misc/mkstemp.c | 12 +--- 1 file changed, 5 insertions(+), 7 deletions(-) Thanks for the patch. Pushed to master now. -- Best regards, LIU Hao OpenPGP_signature.asc Description: OpenPGP digital signature ___ 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
在 2024-03-23 18:43, Pali Rohár 写道: On Monday 11 March 2024 19:02:09 LIU Hao wrote: 在 2024-03-11 15:52, Pali Rohár 写道: I know, but I'm trying to achieve it by small steps. For _scprintf it should fix this issue as mingw library starts providing required symbol for linking object files. Or do you see there some problem with it? That's acceptable, like 'ucrt_vfprintf.c' for example. Ok, and this is what the change "crt: Add non-inline variant of UCRT _scprintf, _snprintf and _snscanf functions" is doing. Link: https://sourceforge.net/p/mingw-w64/mailman/message/37708936/ That single patch causes errors like ``` x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -m32 -masm=att -D__LIBMSVCRT__ -I./include "-I/ucrt64/include" -pipe -std=gnu99 -D_CRTBLD -D_WIN32_WINNT=0x0f00 -D__MSVCRT_VERSION__=0x700 -D__USE_MINGW_ANSI_STDIO=0 -Wall -Wextra -Wformat -Wstrict-aliasing -Wshadow -Wpacked -Winline -Wimplicit-function-declaration -Wmissing-noreturn -Wmissing-prototypes -g -O2 -c -o stdio/lib32_libucrt_extra_a-ucrt__scprintf.o `test -f 'stdio/ucrt__scprintf.c' || echo './'`stdio/ucrt__scprintf.c stdio/ucrt__scprintf.c:12:13: error: redefinition of '_scprintf' 12 | int __cdecl _scprintf(const char * __restrict__ _Format, ...) | ^ In file included from stdio/ucrt__scprintf.c:9: C:/msys64/ucrt64/include/stdio.h:741:15: note: previous definition of '_scprintf' with type 'int(const char * restrict, ...)' 741 | int __cdecl _scprintf(const char * __restrict__ _Format,...) | ^ ``` -- Best regards, LIU Hao OpenPGP_signature.asc Description: OpenPGP digital signature ___ 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
在 2024-03-11 15:52, Pali Rohár 写道: I know, but I'm trying to achieve it by small steps. For _scprintf it should fix this issue as mingw library starts providing required symbol for linking object files. Or do you see there some problem with it? That's acceptable, like 'ucrt_vfprintf.c' for example. -- Best regards, LIU Hao OpenPGP_signature.asc Description: OpenPGP digital signature ___ 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
在 2024-03-09 23:58, Pali Rohár 写道: The point is that this one change allows to have object file with function calls to _scprintf or _snprintf to be CRT independent. Let me guess, you have an object file (maybe in a static library) which was compiled for MSVCRT (or an old variant, at least not UCRT), and you would like to compile some code for UCRT, but to link with the aforementioned object file, or vice versa; is that the case? I'd say code linking against different CRT variants are not compatible. Making `_scprintf` etc. independent about the CRT by de-inlining it for UCRT, does not solve the incompatibility. -- Best regards, LIU Hao OpenPGP_signature.asc Description: OpenPGP digital signature ___ 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
在 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. -- Best regards, LIU Hao OpenPGP_signature.asc Description: OpenPGP digital signature ___ 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
在 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. -- Best regards, LIU Hao OpenPGP_signature.asc Description: OpenPGP digital signature ___ 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
在 2024-03-04 08:04, Mateusz Mikuła 写道: -template_name[j] = letters[rand () % 62]; +if (rand_s ()) return -1; +template_name[j] = letters[r % 62]; Does it make sense that if `rand_s()` fails, use `rand()` as a fallback? We have a custom implementation of `rand_s()` in 'secapi/rand_s.c' which may return `EINVAL` on Windows 2000. -- Best regards, LIU Hao OpenPGP_signature.asc Description: OpenPGP digital signature ___ 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'
在 2024-03-03 04:55, Martin Storsjö 写道: LGTM, thanks! Thanks. Pushed now. -- Best regards, LIU Hao OpenPGP_signature.asc Description: OpenPGP digital signature ___ 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'
在 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.
--
Best regards,
LIU Hao
From beb036474e36685a5b5242a53b744227f18d735e Mon Sep 17 00:00:00 2001
From: LIU Hao
Date: Wed, 28 Feb 2024 23:03:58 +0800
Subject: [PATCH] headers: Move some macros about deprecated functions from
'strsafe.h' into 'dontuse.h'
Since Windows SDK 8.0, `STRSAFE_NO_DEPRECATE` no longer has an effect. It's
still defined by some headers, but the check in 'strsafe.h' has been removed.
Those macros that match POSIX names have been moved to 'dontuse.h', so we do
the same.
Previously, inclusion of before could cause errors like
In file included from C:/msys64/mingw64/include/windows.h:70,
from test.c:2:
C:/msys64/mingw64/include/winbase.h:1499:37: error: expected identifier or
'(' before 'LPSTR'
1499 | WINBASEAPI LPSTR WINAPI lstrcpyA (LPSTR lpString1, LPCSTR
lpString2);
| ^
because the semicolon in the macro `lstrcpyA` affects not only invocations, but
also declarations. Those semicolons have been removed since Windows SDK 8.0, so
we remove them as well. This allows including 'strsafe.h' before 'windows.h'.
The macro `DEPRECATE_SUPPORTED` controls how deprecated functions are to be
deprecated. In Microsoft headers, existence of it deprecates those functions
with `#pragma deprecated`, and absense of it exposes macros which rename them
to non-existent ones, so any use of them results in errors such as
ccYRG0RL.o:test.c:(.text+0x1c): undefined reference to
`strcpy_instead_use_StringCbCopyA_or_StringCchCopyA'
collect2.exe: error: ld returned 1 exit status
To match the behavior of Windows SDK, we define those renaming macros only if
`DEPRECATE_SUPPORTED` isn't defined, like in 'pathcch.h'. Unfortunately, GCC
does not support `#pragma deprecated`, so no warning will be issued if
`DEPRECATE_SUPPORTED` is defined by including 'winnt.h' or 'windows.h' before
'strsafe.h'. This may be improved in the future.
Reported-by: Julian Waters
Signed-off-by: LIU Hao
---
mingw-w64-headers/include/dontuse.h | 161
mingw-w64-headers/include/strsafe.h | 187 +++-
2 files changed, 181 insertions(+), 167 deletions(-)
create mode 100644 mingw-w64-headers/include/dontuse.h
diff --git a/mingw-w64-headers/include/dontuse.h
b/mingw-w64-headers/include/dontuse.h
new file mode 100644
index 0..ac6497c95
--- /dev/null
+++ b/mingw-w64-headers/include/dontuse.h
@@ -0,0 +1,161 @@
+/**
+ * This file has no copyright assigned and is placed in the Public Domain.
+ * This file is part of the mingw-w64 runtime package.
+ * No warranty is given; refer to the file DISCLAIMER.PD within this package.
+ */
+#ifndef _DONTUSE_H_INCLUDED_
+#define _DONTUSE_H_INCLUDED_
+
+#include
+
+#if WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP)
+
+#undef strcpy
+#define strcpy strcpy_instead_use_StringCbCopyA_or_StringCchCopyA
+
+#undef wcscpy
+#define wcscpy wcscpy_instead_use_StringCbCopyW_or_StringCchCopyW
+
+#undef strcat
+#define strcat strcat_instead_use_StringCbCatA_or_StringCchCatA
+
+#undef wcscat
+#define wcscat wcscat_instead_use_StringCbCatW_or_StringCchCatW
+
+#undef sprintf
+#define sprintf sprintf_instead_use_StringCbPrintfA_or_StringCchPrintfA
+
+#undef swprintf
+#define swprintf swprintf_instead_use_StringCbPrintfW_or_StringCchPrintfW
+
+#undef vsprintf
+#define vsprintf vsprintf_instead_use_StringCbVPrintfA_or_StringCchVPrintfA
+
+#undef vswprintf
+#define vswprintf vswprintf_instead_use_StringCbVPrintfW_or_StringCchVPrintfW
+
+#undef _snprintf
+#define _snprintf _snprintf_instead_use_StringCbPrintfA_or_StringCchPrintfA
+
+#undef _snwprintf
+#define _snwprintf _snwprintf_instead_use_StringCbPrintfW_or_StringCchPrintfW
+
+#undef _vsnprintf
+#define _vsnprintf _vsnprintf_instead_use_StringCbVPrintfA_or_StringCchVPrintfA
+
+#undef _vsnwprintf
+#define _vsnwprintf
_vsnwprintf_instead_use_StringCbVPrintfW_or_StringCchVPrintfW
+
+#undef strcpyA
+#define strcpyA strcpyA_instead_use_StringCbCopyA_or_StringCchCopyA
+
+#undef strcpyW
+#define strcpyW strcpyW_instead_use_StringCbCopyW_or_StringCchCopyW
+
+#undef lstrcpy
+#define lstrcpy lstrcpy_instead_use_StringCbCopy_or_StringCchCopy
+
+#undef lstrcpyA
+#define lstrcpyA lstrcpyA_instead_use_StringCbCopyA_or_StringCchCopyA
+
+#undef lstrcpyW
+#define lstrcpyW lstrcpyW_instead_use_StringCbCopyW_or_StringCchCopyW
+
+#undef StrCpy
+#define StrCpy
Re: [Mingw-w64-public] [PATCH 1/3] crt: Add non-inline variant of UCRT _scprintf, _snprintf and _snscanf functions
在 2024-02-29 04:25, Pali Rohár 写道: On Tuesday 09 May 2023 22:29:31 LIU Hao wrote: Our conclusion is that, in order to reduce possible UCRT dependency, moving inline definitions out of headers makes sense; but the other part, such as duplication of functions, will not be accepted. Ok, so does it mean that the one change with title "crt: Add non-inline variant of UCRT _scprintf, _snprintf and _snscanf functions" is fine for you? Or do you need some modification of it? Sort of - but first, I would like to hear about what issue it can solve for you. -- Best regards, LIU Hao OpenPGP_signature.asc Description: OpenPGP digital signature ___ 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'
在 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. 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. Including 'dontuse.h' and getting hard errors might be expected, but including 'strsafe.h' and getting accidental hard errors is probably unwanted. However that's already how Microsoft headers behave. -- Best regards, LIU Hao OpenPGP_signature.asc Description: OpenPGP digital signature ___ 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'
在 2024-02-28 06:01, Martin Storsjö 写道:
Can you mention in the commit message, what used to break if strsafe.h was
included befoe windows.h?
The commit message explains that we're moveing a bunch of macros from strsafe.h into dontuse.h, but
in the diff, I'm also seeing a bunch of other minor changes - the macros for e.g. StringCopyWorkerA
have lost their unnecessary trailing semicolons; can we get that change in a separate commit for
clarity? And I see a new "#ifndef DEPRECATE_SUPPORTED" wrapped around that as well, which also seems
to not be explained in the commit message?
Attached is the updated patch.
There is an unsolved issue about `DEPRECATE_SUPPORTED`: It's a macro that is to be defined by
'winnt.h', so the order of inclusion matters:
$ gcc -xc - && echo $?
#include
#include
int main(void)
{ char t[10]; StringCopyWorkerA(t, sizeof(t), "meow"); }
^Z
0
$ gcc -xc - && echo $?
#include
#include
int main(void)
{ char t[10]; StringCopyWorkerA(t, sizeof(t), "meow"); }
^Z
C:\msys64\tmp\cc1wARDe.o::(.text+0x21): undefined reference to
`StringCopyWorkerA_instead_use_StringCchCopyA_or_StringCchCopyExA'
collect2.exe: error: ld returned 1 exit status
We may provide a local copy of the deprecated attribute in 'strsafe.h', but it would require another
patch.
--
Best regards,
LIU Hao
From 0c578c39c17b94af80dcc91b7ae16c46cda6fd37 Mon Sep 17 00:00:00 2001
From: LIU Hao
Date: Wed, 28 Feb 2024 23:03:58 +0800
Subject: [PATCH] headers: Move some macros about deprecated functions from
'strsafe.h' into 'dontuse.h'
Since Windows SDK 8.0, `STRSAFE_NO_DEPRECATE` no longer has an effect. It's
still defined by some headers, but the check in 'strsafe.h' has been removed.
Those macros that match POSIX names have been moved to 'dontuse.h', so we do
the same.
Previously, inclusion of before could cause errors like
In file included from C:/msys64/mingw64/include/windows.h:70,
from test.c:2:
C:/msys64/mingw64/include/winbase.h:1499:37: error: expected identifier or
'(' before 'LPSTR'
1499 | WINBASEAPI LPSTR WINAPI lstrcpyA (LPSTR lpString1, LPCSTR
lpString2);
| ^
because the semicolon in the macro `lstrcpyA` affects not only invocations, but
also declarations. Those semicolons have been removed since Windows SDK 8.0, so
we remove them as well. This allows including 'strsafe.h' before 'windows.h'.
The effect of `DEPRECATE_SUPPORTED` is a bit complex: It is defined by
'winnt.h'.
In Microsoft headers, it indicates that both `__declspec(deprecated)` and
`#pragma deprecated` are supported. This macro controls whether those functions
are deprecated via pragmas, or with macros. If 'strsafe.h' is include AFTER or
without 'windows.h' and 'winnt.h', then `DEPRECATE_SUPPORTED` is not defined,
and a user may get
ccYRG0RL.o:test.c:(.text+0x1c): undefined reference to
`strcpy_instead_use_StringCbCopyA_or_StringCchCopyA'
collect2.exe: error: ld returned 1 exit status
Unfortunately, GCC does not support `#pragma deprecated`, so there is no warning
if `DEPRECATE_SUPPORTED` is defined (like in 'pathcch.h'). This may be improved
in the future.
Reported-by: Julian Waters
Signed-off-by: LIU Hao
---
mingw-w64-headers/include/dontuse.h | 161
mingw-w64-headers/include/strsafe.h | 187 +++-
2 files changed, 181 insertions(+), 167 deletions(-)
create mode 100644 mingw-w64-headers/include/dontuse.h
diff --git a/mingw-w64-headers/include/dontuse.h
b/mingw-w64-headers/include/dontuse.h
new file mode 100644
index 0..ac6497c95
--- /dev/null
+++ b/mingw-w64-headers/include/dontuse.h
@@ -0,0 +1,161 @@
+/**
+ * This file has no copyright assigned and is placed in the Public Domain.
+ * This file is part of the mingw-w64 runtime package.
+ * No warranty is given; refer to the file DISCLAIMER.PD within this package.
+ */
+#ifndef _DONTUSE_H_INCLUDED_
+#define _DONTUSE_H_INCLUDED_
+
+#include
+
+#if WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP)
+
+#undef strcpy
+#define strcpy strcpy_instead_use_StringCbCopyA_or_StringCchCopyA
+
+#undef wcscpy
+#define wcscpy wcscpy_instead_use_StringCbCopyW_or_StringCchCopyW
+
+#undef strcat
+#define strcat strcat_instead_use_StringCbCatA_or_StringCchCatA
+
+#undef wcscat
+#define wcscat wcscat_instead_use_StringCbCatW_or_StringCchCatW
+
+#undef sprintf
+#define sprintf sprintf_instead_use_StringCbPrintfA_or_StringCchPrintfA
+
+#undef swprintf
+#define swprintf swprintf_instead_use_StringCbPrintfW_or_StringCchPrintfW
+
+#undef vsprintf
+#define vsprintf vsprintf_instead_use_StringCbVPrintfA_or_StringCchVPrintfA
+
+#undef vswprintf
+#define vswprintf vswprintf_instead_use_StringCbVPrintfW_or_StringCchVPrintfW
+
+#undef _snprintf
+#define _snprintf _snprintf_instead_use_StringCbPrintfA_or_StringCchPr
Re: [Mingw-w64-public] [PATCH] include/tchar: Add more macros
在 2024-02-28 06:04, Martin Storsjö 写道: On Mon, 26 Feb 2024, LIU Hao wrote: This should match latest Windows SDK except for `strtold_l()` and `wcstold_l()`. The Microsoft implementations produce 64-bit numbers that do not match the GNU ABI, and we at the moment do not have locale-aware implementations. LGTM, thanks! Thanks. Pushed now. -- Best regards, LIU Hao OpenPGP_signature.asc Description: OpenPGP digital signature ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH] include/tchar: Add more macros
--
Best regards,
LIU Hao
From 0b2dba1baf8698bdcdde615a8a7cdb9d567fe754 Mon Sep 17 00:00:00 2001
From: LIU Hao
Date: Mon, 26 Feb 2024 23:00:13 +0800
Subject: [PATCH] include/tchar: Add more macros
This should match latest Windows SDK except for `strtold_l()` and `wcstold_l()`.
The Microsoft implementations produce 64-bit numbers that do not match the GNU
ABI, and we at the moment do not have locale-aware implementations.
Signed-off-by: LIU Hao
---
mingw-w64-headers/crt/sec_api/tchar_s.h | 10 +-
mingw-w64-headers/crt/tchar.h | 46 -
2 files changed, 54 insertions(+), 2 deletions(-)
diff --git a/mingw-w64-headers/crt/sec_api/tchar_s.h
b/mingw-w64-headers/crt/sec_api/tchar_s.h
index 22e368bc3..405583dd2 100644
--- a/mingw-w64-headers/crt/sec_api/tchar_s.h
+++ b/mingw-w64-headers/crt/sec_api/tchar_s.h
@@ -83,6 +83,7 @@ extern "C" {
#define _tgetenv_s _wgetenv_s
#define _tdupenv_s _wdupenv_s
+#define _tdupenv_s_dbg _wdupenv_s_dbg
#define _tmakepath_s _wmakepath_s
#define _tputenv_s _wputenv_s
#define _tsearchenv_s _wsearchenv_s
@@ -93,11 +94,14 @@ extern "C" {
#define _ttmpnam_s _wtmpnam_s
#define _taccess_s _waccess_s
#define _tmktemp_s _wmktemp_s
+#define _tsopen_s _wsopen_s
#define _tcsnccat_s wcsncat_s
#define _tcsnccat_s_l _wcsncat_s_l
#define _tcsnccpy_s wcsncpy_s
#define _tcsnccpy_s_l _wcsncpy_s_l
+#define _tcsncset_s _wcsnset_s
+#define _tcsncset_s_l _wcsnset_s_l
#define _tcslwr_s _wcslwr_s
#define _tcslwr_s_l _wcslwr_s_l
@@ -166,6 +170,7 @@ extern "C" {
#define _tgetenv_s getenv_s
#define _tdupenv_s _dupenv_s
+#define _tdupenv_s_dbg _dupenv_s_dbg
#define _tmakepath_s _makepath_s
#define _tputenv_s _putenv_s
#define _tsearchenv_s _searchenv_s
@@ -226,11 +231,12 @@ extern "C" {
_CRTIMP char *__cdecl _tcsnccat_s_l(char *_Dst,size_t _DstSizeInChars,const
char *_Src,size_t _MaxCount,_locale_t _Locale);
_CRTIMP char *__cdecl _tcsnccpy_s(char *_Dst,size_t _DstSizeInChars,const
char *_Src,size_t _MaxCount);
_CRTIMP char *__cdecl _tcsnccpy_s_l(char *_Dst,size_t _DstSizeInChars,const
char *_Src,size_t _MaxCount,_locale_t _Locale);
+ _CRTIMP char *__cdecl _tcsncset_s(char *_Str,size_t _SizeInChars,unsigned
int _Val,size_t _MaxCount);
+ _CRTIMP char *__cdecl _tcsncset_s_l(char *_Str,size_t _SizeInChars,unsigned
int _Val,size_t _MaxCount,_locale_t _Locale);
_CRTIMP char *__cdecl _tcslwr_s(char *_Str,size_t _SizeInChars);
_CRTIMP char *__cdecl _tcslwr_s_l(char *_Str,size_t _SizeInChars,_locale_t
_Locale);
_CRTIMP char *__cdecl _tcsupr_s(char *_Str,size_t _SizeInChars);
_CRTIMP char *__cdecl _tcsupr_s_l(char *_Str,size_t _SizeInChars,_locale_t
_Locale);
-
#endif
#else
@@ -252,6 +258,8 @@ extern "C" {
#define _tcsnccat_s_l _strncat_s_l
#define _tcsnccpy_s strncpy_s
#define _tcsnccpy_s_l _strncpy_s_l
+#define _tcsncset_s _strnset_s
+#define _tcsncset_s_l _strnset_s_l
#define _tcslwr_s _strlwr_s
#define _tcslwr_s_l _strlwr_s_l
diff --git a/mingw-w64-headers/crt/tchar.h b/mingw-w64-headers/crt/tchar.h
index 5ae9479c6..14e0069e0 100644
--- a/mingw-w64-headers/crt/tchar.h
+++ b/mingw-w64-headers/crt/tchar.h
@@ -211,30 +211,44 @@ extern "C" {
#define _tcstof wcstof
#define _tcstod wcstod
+#define _tcstold wcstold
#define _tcstol wcstol
#define _tcstoul wcstoul
+#define _tcstoll _wcstoi64
+#define _tcstoull _wcstoui64
#define _tcstoi64 _wcstoi64
#define _tcstoui64 _wcstoui64
+#define _tcstoimax _wcstoi64
+#define _tcstoumax _wcstoui64
#define _tstof _wtof
#define _tstol _wtol
#define _tstoi _wtoi
+#define _tstoll _wtoi64
#define _tstoi64 _wtoi64
#define _tcstof_l _wcstof_l
#define _tcstod_l _wcstod_l
+/* TODO: #define _tcstold_l _wcstold_l */
#define _tcstol_l _wcstol_l
#define _tcstoul_l _wcstoul_l
+#define _tcstoll_l _wcstoi64_l
+#define _tcstoull_l _wcstoui64_l
#define _tcstoi64_l _wcstoi64_l
#define _tcstoui64_l _wcstoui64_l
+#define _tcstoimax_l _wcstoi64_l
+#define _tcstoumax_l _wcstoui64_l
#define _tstof_l _wtof_l
#define _tstol_l _wtol_l
+#define _tstoll_l _wtoi64_l
#define _tstoi_l _wtoi_l
#define _tstoi64_l _wtoi64_l
#define _itot _itow
#define _ltot _ltow
#define _ultot _ultow
+#define _ttof _wtof
#define _ttoi _wtoi
#define _ttol _wtol
+#define _ttoll _wtoi64
#define _ttoi64 _wtoi64
#define _i64tot _i64tow
@@ -260,6 +274,7 @@ extern "C" {
#define __tcserror __wcserror
#define _tcsdup _wcsdup
+#define _tcsdup_dbg _wcsdup_dbg
#define _tcsnset _wcsnset
#define _tcsnset_l _wcsnset_l
#define _tcsrev _wcsrev
@@ -317,18 +332,22 @@ extern "C" {
#define _tstrdate _wstrdate
#define _tstrtime _wstrtime
#define _tutime _wutime
-#define _tutime32 _wutime
+#define _tutime32 _wutime32
#define _tutime64 _wutime64
#define _tcsftime wcsftime
#define _tcsftime_l _wcsftime_l
#define _tchdir _wchdir
#define _tgetcwd _wgetcwd
+#define _tgetcwd_dbg _wgetcwd_dbg
#define _tgetdcwd _wgetdcwd
[Mingw-w64-public] [PATCH] headers: Move some macros about deprecated functions from 'strsafe.h' into 'dontuse.h'
-- Best regards, LIU Hao From f6bbea6b0530ff47da5c1abefef3182933fd8641 Mon Sep 17 00:00:00 2001 From: LIU Hao Date: Wed, 21 Feb 2024 22:51:59 +0800 Subject: [PATCH] headers: Move some macros about deprecated functions from 'strsafe.h' into 'dontuse.h' Since Windows SDK 8.0, `STRSAFE_NO_DEPRECATE` no longer has an effect. It's still defined by some headers, but the check in 'strsafe.h' has been removed. Those macros that match POSIX names have been moved to 'dontuse.h', so we do the same. This allows including 'strsafe.h' before 'windows.h'. Reported-by: Julian Waters Signed-off-by: LIU Hao --- mingw-w64-headers/include/dontuse.h | 161 mingw-w64-headers/include/strsafe.h | 187 +++- 2 files changed, 181 insertions(+), 167 deletions(-) create mode 100644 mingw-w64-headers/include/dontuse.h diff --git a/mingw-w64-headers/include/dontuse.h b/mingw-w64-headers/include/dontuse.h new file mode 100644 index 0..ac6497c95 --- /dev/null +++ b/mingw-w64-headers/include/dontuse.h @@ -0,0 +1,161 @@ +/** + * This file has no copyright assigned and is placed in the Public Domain. + * This file is part of the mingw-w64 runtime package. + * No warranty is given; refer to the file DISCLAIMER.PD within this package. + */ +#ifndef _DONTUSE_H_INCLUDED_ +#define _DONTUSE_H_INCLUDED_ + +#include + +#if WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP) + +#undef strcpy +#define strcpy strcpy_instead_use_StringCbCopyA_or_StringCchCopyA + +#undef wcscpy +#define wcscpy wcscpy_instead_use_StringCbCopyW_or_StringCchCopyW + +#undef strcat +#define strcat strcat_instead_use_StringCbCatA_or_StringCchCatA + +#undef wcscat +#define wcscat wcscat_instead_use_StringCbCatW_or_StringCchCatW + +#undef sprintf +#define sprintf sprintf_instead_use_StringCbPrintfA_or_StringCchPrintfA + +#undef swprintf +#define swprintf swprintf_instead_use_StringCbPrintfW_or_StringCchPrintfW + +#undef vsprintf +#define vsprintf vsprintf_instead_use_StringCbVPrintfA_or_StringCchVPrintfA + +#undef vswprintf +#define vswprintf vswprintf_instead_use_StringCbVPrintfW_or_StringCchVPrintfW + +#undef _snprintf +#define _snprintf _snprintf_instead_use_StringCbPrintfA_or_StringCchPrintfA + +#undef _snwprintf +#define _snwprintf _snwprintf_instead_use_StringCbPrintfW_or_StringCchPrintfW + +#undef _vsnprintf +#define _vsnprintf _vsnprintf_instead_use_StringCbVPrintfA_or_StringCchVPrintfA + +#undef _vsnwprintf +#define _vsnwprintf _vsnwprintf_instead_use_StringCbVPrintfW_or_StringCchVPrintfW + +#undef strcpyA +#define strcpyA strcpyA_instead_use_StringCbCopyA_or_StringCchCopyA + +#undef strcpyW +#define strcpyW strcpyW_instead_use_StringCbCopyW_or_StringCchCopyW + +#undef lstrcpy +#define lstrcpy lstrcpy_instead_use_StringCbCopy_or_StringCchCopy + +#undef lstrcpyA +#define lstrcpyA lstrcpyA_instead_use_StringCbCopyA_or_StringCchCopyA + +#undef lstrcpyW +#define lstrcpyW lstrcpyW_instead_use_StringCbCopyW_or_StringCchCopyW + +#undef StrCpy +#define StrCpy StrCpy_instead_use_StringCbCopy_or_StringCchCopy + +#undef StrCpyA +#define StrCpyA StrCpyA_instead_use_StringCbCopyA_or_StringCchCopyA + +#undef StrCpyW +#define StrCpyW StrCpyW_instead_use_StringCbCopyW_or_StringCchCopyW + +#undef _tcscpy +#define _tcscpy _tcscpy_instead_use_StringCbCopy_or_StringCchCopy + +#undef _ftcscpy +#define _ftcscpy _ftcscpy_instead_use_StringCbCopy_or_StringCchCopy + +#undef lstrcat +#define lstrcat lstrcat_instead_use_StringCbCat_or_StringCchCat + +#undef lstrcatA +#define lstrcatA lstrcatA_instead_use_StringCbCatA_or_StringCchCatA + +#undef lstrcatW +#define lstrcatW lstrcatW_instead_use_StringCbCatW_or_StringCchCatW + +#undef StrCat +#define StrCat StrCat_instead_use_StringCbCat_or_StringCchCat + +#undef StrCatA +#define StrCatA StrCatA_instead_use_StringCbCatA_or_StringCchCatA + +#undef StrCatW +#define StrCatW StrCatW_instead_use_StringCbCatW_or_StringCchCatW + +#undef StrNCat +#define StrNCat StrNCat_instead_use_StringCbCatN_or_StringCchCatN + +#undef StrNCatA +#define StrNCatA StrNCatA_instead_use_StringCbCatNA_or_StringCchCatNA + +#undef StrNCatW +#define StrNCatW StrNCatW_instead_use_StringCbCatNW_or_StringCchCatNW + +#undef StrCatN +#define StrCatN StrCatN_instead_use_StringCbCatN_or_StringCchCatN + +#undef StrCatNA +#define StrCatNA StrCatNA_instead_use_StringCbCatNA_or_StringCchCatNA + +#undef StrCatNW +#define StrCatNW StrCatNW_instead_use_StringCbCatNW_or_StringCchCatNW + +#undef _tcscat +#define _tcscat _tcscat_instead_use_StringCbCat_or_StringCchCat + +#undef _ftcscat +#define _ftcscat _ftcscat_instead_use_StringCbCat_or_StringCchCat + +#undef wsprintf +#define wsprintf wsprintf_instead_use_StringCbPrintf_or_StringCchPrintf + +#undef wsprintfA +#define wsprintfA wsprintfA_instead_use_StringCbPrintfA_or_StringCchPrintfA + +#undef wsprintfW +#define wsprintfW wsprintfW_instead_use_StringCbPrintfW_or_StringCchPrintfW + +#undef wvsprintf +#define wvsprintf wvsprintf_instead_use_StringCbVPrintf_or_StringCchVPrintf
Re: [Mingw-w64-public] [PATCH] Ignore _FORTIFY_SOURCE if __MINGW32__ is not defined
在 2024-02-19 16:22, Christian Franke 写道: It does no harm to define __MINGW_FORTIFY_LEVEL to 0 in the !__MINGW32__ case as done with the patch. Leaving it undefined would make no difference for Cygwin builds. Yes, absolutely. The patch looks good to me. Pushed to master now. Thanks. -- Best regards, LIU Hao OpenPGP_signature.asc Description: OpenPGP digital signature ___ 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] Ignore _FORTIFY_SOURCE if __MINGW32__ is not defined
在 2024-02-19 15:56, Christian Franke 写道: The __MINGW_FORTIFY_LEVEL set in _mingw_mac.h has no effect if a program including Win32 API headers like windows.h is compiled for Cygwin (same applies possibly to MSYS2). The __MINGW_FORTIFY_LEVEL only affects Libc includes which are not present in the Cygwin Win32 API header package (https://cygwin.com/packages/summary/w32api-headers.html). Cygwin provides its own libc headers with different (and more limited) _FORTIFY_SOURCE support. So the idea is that `__MINGW_FORTIFY_LEVEL` should only be defined when a user asks for the mingw-w64 CRT; in the case of Cygwin, mingw-w64 headers are included but the CRT is the Cygwin CRT, so it shouldn't be defined; is that right? The patch should be sensible. Let me have a look later. -- Best regards, LIU Hao OpenPGP_signature.asc Description: OpenPGP digital signature ___ 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] Ignore _FORTIFY_SOURCE if __MINGW32__ is not defined
在 2024-02-19 02:31, Christian Franke 写道: Cygwin's cygport now defaults to _FORTIFY_SOURCE=3 but the stable Cygwin gcc is still 11.4.0 which does not support it. If Cygwin programs include windows.h, this results in bogus warnings or broken builds if -Werror is set. The attached patch fixes this. Well, how about removing that warning, so `_FORTIFY_SOURCE=3` should be equivalent to `2` instead of `0`? -- Best regards, LIU Hao OpenPGP_signature.asc Description: OpenPGP digital signature ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] strsafe.h cannot be included before windows.h
在 2024-02-18 15:40, Julian Waters 写道:
In file included from C:/msys64/ucrt64/include/windows.h:70,
from try.c:4:
C:/msys64/ucrt64/include/winbase.h:1499:37: error: expected identifier
or '(' before 'LPSTR'
1499 | WINBASEAPI LPSTR WINAPI lstrcpyA (LPSTR lpString1, LPCSTR lpString2);
| ^
This file can be pre-processed with `gcc -E -dD`; and this line actually becomes
__attribute__((dllimport)) LPSTR __attribute__((__stdcall__))
lstrcpyA_instead_use_StringCbCopyA_or_StringCchCopyA; (LPSTR lpString1,
LPCSTR lpString2);
which is due to this macro in :
#define lstrcpyA lstrcpyA_instead_use_StringCbCopyA_or_StringCchCopyA;
These macros have been moved from to since Windows SDK 8.0. Maybe we should
do the same.
--
Best regards,
LIU Hao
OpenPGP_signature.asc
Description: OpenPGP digital signature
___
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] gendef: Remove printing __DATE__, to improve build reproducibility
在 2024-02-06 17:34, Martin Storsjö 写道: This tool isn't evolving particularly much at the moment, so the additional value of knowing when a particular version was built doesn't give much extra value. Normally, a stripped build of gendef (on Linux) produces a binary with the exact same hash each time. Using __DATE__ breaks that reproducibility, if rebuilt on different days. It is possible to avoid the issue by setting SOURCE_DATE_EPOCH to a fixed value when building, but in this case, I think the printed date doesn't add much value, so we could simply remove it. Most other similar tools don't contain such printouts. Signed-off-by: Martin Storsjö --- mingw-w64-tools/gendef/src/gendef.c | 1 - 1 file changed, 1 deletion(-) This patch looks good to me. Thanks. Ideally I would expect there to be a version string. A build date provides little useful information, so it may be removed for simplicity. -- Best regards, LIU Hao OpenPGP_signature.asc Description: OpenPGP digital signature ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] __pformat_fpreg_bits: change to match __gdtoa prototype
在 2024-01-19 00:01, JonY via Mingw-w64-public 写道: On 1/18/24 12:46, JonY wrote: Attached patch OK? Changes unsigned int to unsigned long to match __gdtoa due to gcc becoming more strict with pointer types. Attached v2 patch, removed #ifdef and made the type Ulong like the prototype. The v2 patch looks good to me. -- Best regards, LIU Hao OpenPGP_signature.asc Description: OpenPGP digital signature ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] __pformat_fpreg_bits: change to match __gdtoa prototype
在 2024-01-18 20:55, Martin Storsjö 写道: On Thu, 18 Jan 2024, JonY via Mingw-w64-public wrote: Attached patch OK? Changes unsigned int to unsigned long to match __gdtoa due to gcc becoming more strict with pointer types. The change is most probably ok, but can you quote the actual warning/error that it fixes - I don't quite see where this struct/union member type would matter for function prototypes to match. (Recent Clang versions are also quite strict with such things, but hasn't errored out on this yet.) In C conversions between pointers (and integer) were implicit. If the code was C++, it would have caused errors long ago. The patch looks good to me, too. Please go ahead and apply. -- Best regards, LIU Hao OpenPGP_signature.asc Description: OpenPGP digital signature ___ 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 8/8] winpthreads: Use GetModuleHandleA to prevent Unicode errors
在 2024/1/11 23:41, Antonin Décimo 写道: The non-suffixed macro GetModuleHandle depends on whether the file is being compiled in Unicode mode or not. Prefer using the char string literal in this simple case. Signed-off-by: Antonin Décimo --- mingw-w64-libraries/winpthreads/src/misc.c | 2 +- mingw-w64-libraries/winpthreads/src/thread.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) In my opinion the W variants should be preferred. Most A functions convert their arguments to wide strings then call their W variants anyway. -- Best regards, LIU Hao OpenPGP_signature.asc Description: OpenPGP digital signature ___ 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: rename SymRegisterCallback64W to SymRegisterCallbackW64
在 2024/1/10 6:36, Oleg Tolmatcev 写道: From 6c3a285c76328440690f9e7493cfcd7be5131bdc Mon Sep 17 00:00:00 2001 From: Oleg Tolmatcev Date: Fri, 29 Dec 2023 14:13:10 +0100 Subject: [PATCH] headers: rename SymRegisterCallback64W to SymRegisterCallbackW64 --- mingw-w64-headers/include/psdk_inc/_dbg_common.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Thanks for the fix. The patch looks good to me. Pushed to master now. -- Best regards, LIU Hao OpenPGP_signature.asc Description: OpenPGP digital signature ___ 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: Remove section attributes from declarations
在 2024/1/11 20:28, Martin Storsjö 写道: LGTM, thanks! (I didn't test it, but these attributes shouldn't indeed have any effect on a declaration.) Thanks, pushed to master now. -- Best regards, LIU Hao OpenPGP_signature.asc Description: OpenPGP digital signature ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Consider regenerating autoconf scripts with autoconf 2.72
在 2024/1/9 0:13, Antonin Décimo 写道: Not so long after we updated to autoconf 2.71, a new release sporting bug fixes was cut. https://lists.gnu.org/archive/html/info-gnu/2023-12/msg2.html Using MSYS2 MINGW64 environment, and with an updated install, the scripts can be regenerated from the top directory with WANT_AUTOMAKE=1.16 WANT_AUTOCONF=2.72 autoreconf -fiv (the patch is too long to be sent over email). Done now. Committed as b4515a6935a3ab49f11c68eaefb95b2bba8c2d20. -- Best regards, LIU Hao OpenPGP_signature.asc Description: OpenPGP digital signature ___ 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: Remove section attributes from declarations
--
Best regards,
LIU Hao
From cd3802aae66bc7c8caaa2cd44473a9e9455ab136 Mon Sep 17 00:00:00 2001
From: LIU Hao
Date: Mon, 8 Jan 2024 21:58:04 +0800
Subject: [PATCH] crt: Remove section attributes from declarations
This patch is generated by
sed -Ei '/\/s/\<_CRTALLOC\([^)]+\) +//' $(git grep -Flr _CRTALLOC)
in order to get rid of warnings like
crt/crtexe.c:58:1: warning: 'used' attribute ignored [-Wattributes]
extern _CRTALLOC(".CRT$XIA") _PIFV __xi_a[];
Signed-off-by: LIU Hao
---
mingw-w64-crt/crt/crtdll.c | 8
mingw-w64-crt/crt/crtexe.c | 8
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/mingw-w64-crt/crt/crtdll.c b/mingw-w64-crt/crt/crtdll.c
index e264d4e96..0f08a1a50 100644
--- a/mingw-w64-crt/crt/crtdll.c
+++ b/mingw-w64-crt/crt/crtdll.c
@@ -35,10 +35,10 @@
extern void __cdecl _initterm(_PVFV *,_PVFV *);
extern void __main ();
extern void _pei386_runtime_relocator (void);
-extern _CRTALLOC(".CRT$XIA") _PIFV __xi_a[];
-extern _CRTALLOC(".CRT$XIZ") _PIFV __xi_z[];
-extern _CRTALLOC(".CRT$XCA") _PVFV __xc_a[];
-extern _CRTALLOC(".CRT$XCZ") _PVFV __xc_z[];
+extern _PIFV __xi_a[];
+extern _PIFV __xi_z[];
+extern _PVFV __xc_a[];
+extern _PVFV __xc_z[];
/* TLS initialization hook. */
diff --git a/mingw-w64-crt/crt/crtexe.c b/mingw-w64-crt/crt/crtexe.c
index 03bda5912..1ca9815ef 100644
--- a/mingw-w64-crt/crt/crtexe.c
+++ b/mingw-w64-crt/crt/crtexe.c
@@ -50,10 +50,10 @@ extern _CRTIMP void __cdecl _initterm(_PVFV *, _PVFV *);
static int __cdecl check_managed_app (void);
-extern _CRTALLOC(".CRT$XIA") _PIFV __xi_a[];
-extern _CRTALLOC(".CRT$XIZ") _PIFV __xi_z[];
-extern _CRTALLOC(".CRT$XCA") _PVFV __xc_a[];
-extern _CRTALLOC(".CRT$XCZ") _PVFV __xc_z[];
+extern _PIFV __xi_a[];
+extern _PIFV __xi_z[];
+extern _PVFV __xc_a[];
+extern _PVFV __xc_z[];
/* TLS initialization hook. */
--
2.43.0
OpenPGP_signature.asc
Description: OpenPGP digital signature
___
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: Add processsnapshot.h
在 2024/1/1 2:47, Biswapriyo Nath 写道: From 73bb3f8f6c547aca754046b0b8b6d63696ef31b6 Mon Sep 17 00:00:00 2001 From: Biswapriyo Nath Date: Sun, 31 Dec 2023 18:44:45 + Subject: [PATCH] headers: Add processsnapshot.h Required forhttps://github.com/python/cpython/blob/v3.12.0/Modules/posixmodule.c Signed-off-by: Biswapriyo Nath --- mingw-w64-headers/include/processsnapshot.h | 299 1 file changed, 299 insertions(+) create mode 100644 mingw-w64-headers/include/processsnapshot.h Thanks for the patch. Pushed to master now. And, happy new year! -- Best regards, LIU Hao OpenPGP_signature.asc Description: OpenPGP digital signature ___ 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: Add a noreturn attribute on RtlRestoreContext
在 2023/12/22 18:34, Martin Storsjö 写道: This should have less critical effect on code generation compared to marking RtlCaptureContext as returns_twice, but can avoid compiler warnings in some cases (although I don't have such a case at hand right now). Signed-off-by: Martin Storsjö --- mingw-w64-headers/include/winnt.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Looks good to me, too. I actually had a look at Wine's implementation. This function calls `NtContinue()` which is a request to replace the execution context, so it's likely not to return. -- Best regards, LIU Hao OpenPGP_signature.asc Description: OpenPGP digital signature ___ 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: Add the returns_twice attribute on the RtlCaptureContext function
在 2023/12/22 05:01, Martin Storsjö 写道: This allows the compiler to generate correct code to resume execution when returning to this point later. Signed-off-by: Martin Storsjö --- mingw-w64-headers/include/winnt.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) This patch looks good to me. -- Best regards, LIU Hao OpenPGP_signature.asc Description: OpenPGP digital signature ___ 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 PPROC_THREAD_ATTRIBUTE_LIST in PARTITION_APP
在 2023/12/13 18:56, Steve Lhomme 写道: It's needed by CreateProcess (via STARTUPINFOEX) which is available in UWP apps. --- mingw-w64-headers/include/processthreadsapi.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Thanks for the patch. Pushed to master now. -- Best regards, LIU Hao OpenPGP_signature.asc Description: OpenPGP digital signature ___ 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: Replace some IDs with header files in strmiids library
在 2023/12/16 22:33, LIU Hao 写道: 在 2023/12/16 22:03, Biswapriyo Nath 写道: I shall include the uuids.h and remove the duplicates in strmiids.h. That would be similar as wine/libs/strmiids/strmiids.c. Latest patch file is attached. Thanks for the update. Pushed now. BTW, I have noticed that some GUIDs are available from headers (e.g. `IID_ICreatePropBagOnRegKey`) and some are not (e.g. `IID_ITVEMCastManager`). Eventually we should include those headers and use the definitions in there to eliminate duplication, like Wine does. -- Best regards, LIU Hao OpenPGP_signature.asc Description: OpenPGP digital signature ___ 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: Replace some IDs with header files in strmiids library
在 2023/12/16 22:03, Biswapriyo Nath 写道: I shall include the uuids.h and remove the duplicates in strmiids.h. That would be similar as wine/libs/strmiids/strmiids.c. Latest patch file is attached. Thanks for the update. Pushed now. -- Best regards, LIU Hao OpenPGP_signature.asc Description: OpenPGP digital signature ___ 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: Replace some IDs with header files in strmiids library
在 2023/12/15 11:41, Biswapriyo Nath 写道: From f2718f6525e1fef2333846921c4aebdf75414bfb Mon Sep 17 00:00:00 2001 From: Biswapriyo Nath Date: Fri, 15 Dec 2023 03:38:58 + Subject: [PATCH 2/2] crt: Replace some IDs with header files in strmiids library Signed-off-by: Biswapriyo Nath --- mingw-w64-crt/libsrc/strmiids.c | 123 +++- 1 file changed, 8 insertions(+), 115 deletions(-) What's the purpose about this change? Some of these UUIDs are still defined with `DEFINE_GUID` in both 'uuids.h' and 'strmiids.c' so do you know a reason behind that? -- Best regards, LIU Hao OpenPGP_signature.asc Description: OpenPGP digital signature ___ 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 Makefile.am error introduced in efb61884c4
在 2023/12/12 9:30, Mark Harmstone 写道: Signed-off-by: Mark Harmstone --- mingw-w64-crt/Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Many thanks for these patches. Pushed to master now. -- Best regards, LIU Hao OpenPGP_signature.asc Description: OpenPGP digital signature ___ 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 dhcpcsvc6 for arm64 too
在 2023/12/4 21:14, Martin Storsjö 写道:
Signed-off-by: Martin Storsjö
---
.../{lib64 => lib-common}/dhcpcsvc6.def | 0
mingw-w64-crt/libarm32/dhcpcsvc6.def | 29 ---
mingw-w64-crt/libarm64/Makefile.am| 1 +
3 files changed, 1 insertion(+), 29 deletions(-)
rename mingw-w64-crt/{lib64 => lib-common}/dhcpcsvc6.def (100%)
delete mode 100644 mingw-w64-crt/libarm32/dhcpcsvc6.def
This patch looks good to me.
Send again as I just noticed I had used another account.
--
Best regards,
LIU Hao
OpenPGP_signature.asc
Description: OpenPGP digital signature
___
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 dhcpcsvc6 for arm64 too
在 2023/12/4 21:14, Martin Storsjö 写道:
Signed-off-by: Martin Storsjö
---
.../{lib64 => lib-common}/dhcpcsvc6.def | 0
mingw-w64-crt/libarm32/dhcpcsvc6.def | 29 ---
mingw-w64-crt/libarm64/Makefile.am| 1 +
3 files changed, 1 insertion(+), 29 deletions(-)
rename mingw-w64-crt/{lib64 => lib-common}/dhcpcsvc6.def (100%)
delete mode 100644 mingw-w64-crt/libarm32/dhcpcsvc6.def
This patch looks good to me.
--
Best regards,
LIU Hao
OpenPGP_signature.asc
Description: OpenPGP digital signature
___
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/ksmedia: Tiny fixes to match Windows SDK
在 2023/12/3 18:43, Martin Storsjö 写道: LGTM Thanks. Pushed now. -- Best regards, LIU Hao OpenPGP_signature.asc Description: OpenPGP digital signature ___ 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/ksmedia: Tiny fixes to match Windows SDK
在 2023/12/2 10:29, Kacper Michajłow 写道:
Missing comma in this line:
https://github.com/mingw-w64/mingw-w64/blob/662e1305f86aa797eb7c79c5ae9c63137c79d855/mingw-w64-headers/include/ksmedia.h#L668
<https://github.com/mingw-w64/mingw-w64/blob/662e1305f86aa797eb7c79c5ae9c63137c79d855/mingw-w64-headers/include/ksmedia.h#L668>
Regressed by:
01d406a
<https://github.com/mingw-w64/mingw-w64/commit/01d406ab4d6ccbd1d3b7807ca81d081c88ee204e>
Windows SDK headers (7.1, 8.0, 8.1, 10.0.18362.0, 10.0.19041.0, 10.0.20348.0, 10.0.22000.0,
10.0.22621.0) only have a few GUIDs in `_INC_MMREG`, from `STATIC_KSDATAFORMAT_SUBTYPE_IEEE_FLOAT`
to `STATIC_KSDATAFORMAT_SUBTYPE_MPEG`. So probably those new GUIDs should have been defined outside
that block.
--
Best regards,
LIU Hao
From 7f54c78e35c2056a6d972261d70e8ba8fbf1191a Mon Sep 17 00:00:00 2001
From: LIU Hao
Date: Sat, 2 Dec 2023 14:51:58 +0800
Subject: [PATCH] headers/ksmedia: Tiny fixes to match Windows SDK
Add a missing comma; move `STATIC_KSDATAFORMAT_SUBTYPE_IEC61937_DOLBY_DIGITAL`
and `STATIC_KSDATAFORMAT_SUBTYPE_IEC61937_DTS` outside `#ifdef _INC_MMREG` so
they match Windows SDK 10.0.22621.0.
This closes https://github.com/mingw-w64/mingw-w64/issues/40.
Signed-off-by: LIU Hao
---
mingw-w64-headers/include/ksmedia.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mingw-w64-headers/include/ksmedia.h
b/mingw-w64-headers/include/ksmedia.h
index 63ac78f82..0cbe3c006 100644
--- a/mingw-w64-headers/include/ksmedia.h
+++ b/mingw-w64-headers/include/ksmedia.h
@@ -652,6 +652,7 @@
DEFINE_GUIDSTRUCT("0002--0010-8000-00aa00389b71",KSDATAFORMAT_SUBTYPE_AD
DEFINE_WAVEFORMATEX_GUID(WAVE_FORMAT_MPEG)
DEFINE_GUIDSTRUCT("0050--0010-8000-00aa00389b71",KSDATAFORMAT_SUBTYPE_MPEG);
#define KSDATAFORMAT_SUBTYPE_MPEG DEFINE_GUIDNAMED(KSDATAFORMAT_SUBTYPE_MPEG)
+#endif /* _INC_MMREG */
#define STATIC_KSDATAFORMAT_SUBTYPE_IEC61937_DOLBY_DIGITAL \
DEFINE_WAVEFORMATEX_GUID(WAVE_FORMAT_DOLBY_AC3_SPDIF)
@@ -662,10 +663,9 @@
DEFINE_GUIDSTRUCT("0092--0010-8000-00aa00389b71",KSDATAFORMAT_SUBTYPE_IE
DEFINE_WAVEFORMATEX_GUID(WAVE_FORMAT_DTS)
DEFINE_GUIDSTRUCT("0008--0010-8000-00aa00389b71",KSDATAFORMAT_SUBTYPE_IEC61937_DTS);
#define KSDATAFORMAT_SUBTYPE_IEC61937_DTS
DEFINE_GUIDNAMED(KSDATAFORMAT_SUBTYPE_IEC61937_DTS)
-#endif /* _INC_MMREG */
#define STATIC_KSDATAFORMAT_SUBTYPE_IEC61937_DTS_HD\
- 0x000b,0x0cea,0x0010,0x80,0x00,0x00,0xaa,0x00,0x38,0x9b 0x71
+ 0x000b,0x0cea,0x0010,0x80,0x00,0x00,0xaa,0x00,0x38,0x9b,0x71
DEFINE_GUIDSTRUCT("000b-0cea-0010-8000-00aa00389b71",KSDATAFORMAT_SUBTYPE_IEC61937_DTS_HD);
#define KSDATAFORMAT_SUBTYPE_IEC61937_DTS_HD
DEFINE_GUIDNAMED(KSDATAFORMAT_SUBTYPE_IEC61937_DTS_HD)
--
2.42.1
OpenPGP_signature.asc
Description: OpenPGP digital signature
___
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 14/18] winpthreads: AC_PROG_RANLIB is obsoleted by LT_INIT
在 2023/11/30 18:54, Antonin Décimo 写道: Are you sure it's a good idea? Isn't it better if the two files are kept in sync? It's less confusing during the occasional bisect. In OCaml, we even have continuous integration testing that configure is regenerated on configure.ac changes. Changes to generated files can't be reviewed or cherry-picked; and they may be overwritten anyway. So there is no necessity to include them. They will be committed separately. -- Best regards, LIU Hao OpenPGP_signature.asc Description: OpenPGP digital signature ___ 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/18] winpthreads: Format error string with snprintf
在 2023/11/29 18:38, Antonin Décimo 写道:
Previous code was too complex and hard to understand, and snprintf
fits the job nicely.
Signed-off-by: Antonin Décimo
---
mingw-w64-libraries/winpthreads/src/thread.c | 21
1 file changed, 4 insertions(+), 17 deletions(-)
+ char threaderr[sizeof(THREADERR) + 8] = { 0 };
+ snprintf(threaderr, sizeof(threaderr), THREADERR, GetCurrentThreadId());
There wasn't `snprintf()` in MSVCRT.DLL from Windows XP. I think `sprintf()` should be called here,
as the length of the output string has an upper limit.
--
Best regards,
LIU Hao
OpenPGP_signature.asc
Description: OpenPGP digital signature
___
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: include some IEC61937 GUID
在 2023/11/29 19:04, Steve Lhomme 写道:
+#define STATIC_KSDATAFORMAT_SUBTYPE_IEC61937_DOLBY_DIGITAL \
+ DEFINE_WAVEFORMATEX_GUID(WAVE_FORMAT_DOLBY_AC3_SPDIF)
+DEFINE_GUIDSTRUCT("0092--0010-8000-00aa00389b71",KSDATAFORMAT_SUBTYPE_IEC61937_DOLBY_DIGITAL);
+#define KSDATAFORMAT_SUBTYPE_IEC61937_DOLBY_DIGITAL
DEFINE_GUIDNAMED(KSDATAFORMAT_SUBTYPE_IEC61937_DOLBY_DIGITAL)
+
+#define STATIC_KSDATAFORMAT_SUBTYPE_IEC61937_DTS \
+ DEFINE_WAVEFORMATEX_GUID(WAVE_FORMAT_DOLBY_AC3_SPDIF)
^~~
This was an apparent oversight; it should be `WAVE_FORMAT_DTS`.
Thanks for the patches. Amended and pushed to master now.
--
Best regards,
LIU Hao
OpenPGP_signature.asc
Description: OpenPGP digital signature
___
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] Update to latest config.guess and config.sub
在 2023/11/23 22:16, Antonin Décimo 写道: May I ask on which system you regenerated the files? I need to regenerate some files after a little change, and I'm getting unrelated diffs in the files. I regenerated those files with latest (at that moment) MSYS2. The next day I also tried these on Linux Mint: ``` lh_mouse@lhmouse-xps ~ $ automake --version automake (GNU automake) 1.16.5 ... lh_mouse@lhmouse-xps ~ $ autoconf --version autoconf (GNU Autoconf) 2.71 ``` ... and there were indeed some differences about K vs. ISO prototypes and addition/removal of some target triplets, but I believed those should be safe. -- Best regards, LIU Hao OpenPGP_signature.asc Description: OpenPGP digital signature ___ 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: cast fd to SOCKET in macros
在 2023/11/25 15:59, LIU Hao 写道: I don't think the patch is necessary. Windows socket handles are represented as `UINT_PTR` instead of plain `int`. On 64-bit Windows, storing a socket handle into `int` might cause truncation and is not safe. Also, please read this reply: https://github.com/openssl/openssl/issues/7282#issuecomment-430633656 Some people have conditional typedefs for socket types so they use `SOCKET` on Windows and there will be no such warning. Some others (like OpenSSL) always use `int` and save four bytes; while we can assume this usually just 'works', it will be necessary to cast socket handles back to `SOCKET` from `int` when using Windows socket APIs. -- Best regards, LIU Hao OpenPGP_signature.asc Description: OpenPGP digital signature ___ 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: cast fd to SOCKET in macros
在 2023/11/25 7:56, Oleg Tolmatcev 写道:
Socket.cpp:762:5: warning: comparison of integers of different signs:
'SOCKET' (aka 'unsigned long long') and 'const s32' (aka 'const int')
[-Wsign-compare]
762 | FD_SET(fd, _fds);
| ^~
C:/msys64/clang64/include/psdk_inc/_fd_types.h:77:40: note: expanded
from macro 'FD_SET'
77 | if (((fd_set *)(set))->fd_array[__i] == (fd))
{ \
| ^ ~~
This happens because on Windows a socket is unsigned and on Linux it
is signed and this is cross platform code.
I don't think the patch is necessary. Windows socket handles are represented as `UINT_PTR` instead
of plain `int`. On 64-bit Windows, storing a socket handle into `int` might cause truncation and is
not safe.
--
Best regards,
LIU Hao
OpenPGP_signature.asc
Description: OpenPGP digital signature
___
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] Update to latest config.guess and config.sub
在 2023/11/16 23:36, Antonin Décimo 写道: There are commits solely for updating generated files. Usually not all files get updated, however they can be forced regenerated with `autoreconf -f`. Updated now [1]. Thank you for having considered this. May I ask why you chose automake 1.15.1 rather than 1.16.5 to regenerate configure? Granted, I've looked at the diff, and it does seem minor. I don't know; that was just `autoreconf` selected. I will take a look later today. -- Best regards, LIU Hao OpenPGP_signature.asc Description: OpenPGP digital signature ___ 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] Update to latest config.guess and config.sub
在 2023-11-16 18:10, Antonin Décimo 写道: I don't think that's entirely correct. The `configure.ac` scripts are specific to a project and require a minimum version of autoconf (see `AC_PREREQ` [1]). When updating to autoconf-2.71 I found just one deprecation warning in winpthreads/. These scripts never get updated automatically, they're written by project authors. Well, some of the may be safely removed, such as `AC_HEADER_TIME`. This is can be done with `autoupdate`. If the project already provides `configure`, it's unlikely anyone will regenerate it, which is why I think there's value in providing a regenerated `configure` from the latest autotools. A lot of work has been done between 2.69 and 2.71, see "Rejuvenating Autotools" [3]. There are also precedents in mingw-w64's history (which prompted me to submit these patches): There are commits solely for updating generated files. Usually not all files get updated, however they can be forced regenerated with `autoreconf -f`. Updated now [1]. [1] https://sourceforge.net/p/mingw-w64/mingw-w64/ci/b6de4ef -- Best regards, LIU Hao OpenPGP_signature.asc Description: OpenPGP digital signature ___ 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] Update to latest config.guess and config.sub
在 2023/11/16 00:24, Antonin Décimo 写道: For these two scripts, the thing is that autotools vendors them, and they can get stuck a bit behind in the past. They've had a handful of patches lately, improving Windows support. We don't stick to a specific version of autotools. Those products of autotools are there for convenience for others who don't have autotools installed; they can be arbitrarily overwritten by whatever happens to exist on a build machine. So, there is no need to send separate patches for them; they will get updated sooner or latter - for example, when MSYS2 has the versions you've proposed. -- Best regards, LIU Hao OpenPGP_signature.asc Description: OpenPGP digital signature ___ 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] Update to latest config.guess and config.sub
在 2023-11-15 20:49, Antonin Décimo 写道: Using commit 28ea239c53a2d5d8800c472bc2452eaa16e37af2 (latest as the time of writing) from https://git.savannah.gnu.org/cgit/config.git/. Signed-off-by: Antonin Décimo --- build-aux/config.guess| 107 +- build-aux/config.sub | 236 +- Those files are generated by autotools automatically. Are there any reasons why we should update them by hand? -- Best regards, LIU Hao OpenPGP_signature.asc Description: OpenPGP digital signature ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Determine whether a mingw-w64 port of gcc is UCRT or MSVCRT
在 2023/11/10 14:51, sisyphus 写道: Given that I have, in my path, a mingw-w64 port of version 13.2.0 of gcc.exe, is there a gcc command that I can run to determine whether this gcc uses UCRT ? I thought that running "gcc --version" would do that - and it does for Brecht Sanders builds ... but niXman's UCRT and MSVCRT builds both report the same for "gcc --version". Is there instead something in "gcc -v" that I should be looking for ? ``` echo '#include ' | x86_64-w64-mingw32-gcc -E -dM -xc - | fgrep _UCRT ``` gives `#define _UCRT` if the headers have been configured to use UCRT by default. -- Best regards, LIU Hao OpenPGP_signature Description: OpenPGP digital signature ___ 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: Check GetModuleHandle return value before calling GetProcAddress
在 2023-11-09 21:27, Martin Storsjö 写道: On Tue, 31 Oct 2023, Martin Storsjö wrote: In Windows Store builds with the winstorecompat library, GetModuleHandle returns null, and GetProcAddress is not documented to allow passing null. Signed-off-by: Martin Storsjö --- mingw-w64-libraries/winpthreads/src/clock.c | 8 +--- mingw-w64-libraries/winpthreads/src/misc.c | 4 +++- mingw-w64-libraries/winpthreads/src/thread.c | 6 -- 3 files changed, 12 insertions(+), 6 deletions(-) Ping This patch looks good to me. Sorry for overlooking. -- Best regards, LIU Hao OpenPGP_signature Description: OpenPGP digital signature ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Define __STDC_NO_THREADS__ if C11/C17 is not provided
在 2023/11/9 15:14, Antonin Décimo 写道: I should be able to test this macro to choose to include `threads.h` or not, even if it is not predefined, it cannot be located in 'threads.h'. Someone may wish to use the same compiler consistently with older and newer C runtime libraries. It is likely cumbersome if the compiler would have had to look for a header before it could define a builtin macro. Is there no mechanism to allow this? gcc+glibc used to support it. Clang currently has the correct behaviour on most systems. Suppose: If clang currently defines `__STDC_NO_THREADS__`, does it stop doing so if we upgrade mingw-w64 so we start to have ? I see some problems here, although it is allowed to define __STDC_VERSION__ in C++ mode, most compilers don't define this macro in C++. `thread_local` is already a C++11 keyword. Yes that's why the macro `thread_local` shouldn't be defined for C++. In C23 the macro `thread_local` is removed, and `thread_local` becomes a keyword too. The `_Thread_local` type specifier is removed. It's a reserved word so a compiler is allowed to still provide it as an extension [1]. And I wonder whether there is a good reason that it will be removed. Keeping it as an extension has little cost, while removing it would break valid C11 code. Besides, providing an incomplete `threads.h` without all the C11 thread functions wouldn't be compliant, and quite counter-intuitive. I'd say it's not good. However, defining `__STDC_NO_THREADS__` in the compiler might not be even better; how can this compiler be used with a newer runtime library that actually provides ? To fix my issue, I might define __STDC_NO_THREADS__ at configure-time if the 'threads.h' header cannot be found. Maybe you can use `__has_include()` to check existence of the header [2]. [1] https://gcc.godbolt.org/z/dxoTj3Eqr [2] https://gcc.gnu.org/onlinedocs/gcc-9.5.0/cpp/_005f_005fhas_005finclude.html -- Best regards, LIU Hao OpenPGP_signature Description: OpenPGP digital signature ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Define __STDC_NO_THREADS__ if C11/C17 is not provided
在 2023/11/9 00:51, Antonin Décimo 写道: I've looked for the __STDC_NO_THREADS__ string in the latest mingw-w64 sources, but could not find it. It would be useful to me to have this macro defined, to write portable C code across platforms, compilers, and to make the code work on C23. Is it possible to add it? Where would be the best location? I think we can add a dummy 'threads.h' that contains solely: ``` #define __STDC_NO_THREADS__ 1 #if defined(__STDC_VERSION__) && (__STDC_VERSION__ >= 201112L) /* C11 and not C++ */ # define thread_local _Thread_local #endif ``` ISO C seems to require it to be a predefined macro without inclusion of any headers (6.10.8 1 Predefined macro names, N1570, ISO/IEC 9899:201x), but that will have to be done in the compiler and I don't think it has something to do with the compiler. -- Best regards, LIU Hao OpenPGP_signature Description: OpenPGP digital signature ___ 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: Add new symbols in processthreadsapi.h
在 2023-11-02 17:08, Biswapriyo Nath 写道: From 75213b28cb4c15dd2284dbd90e75da4c0fa1cf27 Mon Sep 17 00:00:00 2001 From: Biswapriyo Nath Date: Thu, 2 Nov 2023 09:06:41 + Subject: [PATCH] headers: Add new symbols in processthreadsapi.h Required for pytorch/kineto Signed-off-by: Biswapriyo Nath --- mingw-w64-headers/include/processthreadsapi.h | 56 +-- 1 file changed, 52 insertions(+), 4 deletions(-) Thanks for the patch. Pushed now. -- Best regards, LIU Hao OpenPGP_signature Description: OpenPGP digital signature ___ 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: Mark _tls_used as used for LTO
在 2023-10-31 18:15, Martin Storsjö 写道: 02b4df13b1aac0dba0a35e87f1a536594fd35edd added attribute used to _CRTALLOC, applying it automatically on most such special variables that need to be retained during LTO. _tls_used is also such a variable, but it's not located in any special section; thus apply the attribute directly. Signed-off-by: Martin Storsjö --- mingw-w64-crt/crt/tlssup.c | 1 + 1 file changed, 1 insertion(+) This patch looks good to me, too. -- Best regards, LIU Hao OpenPGP_signature Description: OpenPGP digital signature ___ 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: Revert to our implementation of scalbn/scalbnf and ldexp on UCRT
在 2023-10-31 17:24, Martin Storsjö 写道: The UCRT implementation of scalbn/scalbnf (and presumably ldexp too, as it's an identical function) has a minor spec incompliance; it doesn't respect the rounding mode that has been set. For most uses of scalbn, rounding isn't at play at all; rounding only makes a difference when scaling the floats out of range, for deciding between staying at DBL_MAX or going to infinity, or likewise between the smallest subnormal or going to zero. This is observed in compiler-rt's testsuite for builtins. Signed-off-by: Martin Storsjö --- I submitted a PR to change compiler-rt's tests to ignore this failure at https://github.com/llvm/llvm-project/pull/70776 as well, but if we consider strictness in these corner cases important enough we can certainly do this revert as well. --- mingw-w64-crt/Makefile.am | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) This patch looks good to me. Thanks. -- Best regards, LIU Hao OpenPGP_signature Description: OpenPGP digital signature ___ 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: change LoadLibrary calls to GetModuleHandle after cb7f42e.
在 2023-10-31 21:37, Martin Storsjö 写道: Yes, this is what I meant. The fact that Windows Store apps wouldn't be getting the modern codepath with GetTickCount64, but unconditonally be usin the old fallback codepath of using QueryPerformanceCounter, doesn't seem too bad, so I think that's acceptable. I suspect no further patch is needed? There is still a minor issue: When a module handle to KERNEL32 can't be obtained, we are passing a null handle to `GetProcAddress()`, which then attempts to look the target function in the current executable image, is that desired? -- Best regards, LIU Hao OpenPGP_signature Description: OpenPGP digital signature ___ 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: change LoadLibrary calls to GetModuleHandle after cb7f42e.
在 2023/10/31 16:20, Martin Storsjö 写道: Right. On the other hand, the QueryPerformanceCounter based fallback implementation probably is workable enough for winstore apps as well, I would guess, so perhaps it't not worth making a fuss about in the end anyway. The issue is not about whether there is a fallback; the issue is about when to use the fallback. If we still aim at providing a (static) winpthreads that is eligible for Windows Store apps, then there does not seem any way to detect the existence of `GetTickCount64()`, and as a consequence we would have to use the fallback unconditionally. We also notice that `QueryPerformanceCounter()` is quite fast on modern Windows; the frequency is probably not but that variable isn't gonna change hence can be static anyway. -- Best regards, LIU Hao OpenPGP_signature Description: OpenPGP digital signature ___ 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: change LoadLibrary calls to GetModuleHandle after cb7f42e.
在 2023/10/31 08:06, Jacek Caban 写道: I find the claim that it's fine to wait for longer to be questionable. GetTickCount's value may be off by up to 16 ms, so the way elapsed time is calculated in those helpers may be off by up to 32 ms. I guess that precise waits matter mostly for short timeouts in scenarios where timeouts are semi-expected to happen and then the overhead of over-waiting may be not negligible. I wonder if the observed too short waits are an effect of measurements problems in tests, but I can't judge on that without seeing tests. All operating systems will have some sort of accuracy considerations in this area and kernel is in a better position to handle it than we are. There is a requirement, formally specified in `nanosleep()` [1] which takes a relative timeout, that a program may not wait shorter than requested. On the other hand `pthread_mutex_timedlock()` etc. take absolute timeouts but it seems they are not allowed to wake up prematurely [2], except `pthread_cond_timedwait()` which is subject to spurious wakeups. Given that a program may not wait shorter, it can be concluded that all premature wakeups are either spurious or results of having been interrupted; otherwise the behavior of these functions will be unpredictable. For example, a timed wait function that ignores any request below 100 ms is less likely to be useful. [1] https://pubs.opengroup.org/onlinepubs/9699919799/functions/nanosleep.html [2] https://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_mutex_timedlock.html -- Best regards, LIU Hao OpenPGP_signature Description: OpenPGP digital signature ___ 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: change LoadLibrary calls to GetModuleHandle after cb7f42e.
在 2023-10-30 18:54, Martin Storsjö 写道: FWIW, this is what we already had before cb7f42e05b94cbb1d94edcebdbfb47b652a45484; we used GetTickCount64 unconditionally if _WIN32_WINNT was set to target vista or above. Since f3c53a51df5c08f181e13a39b1cd6fd1d41edb96, our default _WIN32_WINNT is set to target Win10, so a default-built toolchain will have a winpthread that doesn't run on versions below Vista - one of the intents in cb7f42e05b94cbb1d94edcebdbfb47b652a45484 was to make it so that one doesn't need to use a special built toolchain in order to run things on older versions of Windows. There was a reply from Christian Franke which mentioned support for XP, which still requires `GetModuleHandle()` or `LoadLibrary()` somehow. We may decide that Windows 98 is outdated and not primarily (if not completely) supported, but it does not seem to be the case with Windows XP, does it? Do Windows store apps link against the static winpthreads or shared one? maybe it is possible to provide a helper function in winstorecompat which imports `GetTickCount64()` for example, so the statically linked winpthreads can make use of this helper function rather than call `GetModuleHandle()` itself. -- Best regards, LIU Hao OpenPGP_signature Description: OpenPGP digital signature ___ 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: change LoadLibrary calls to GetModuleHandle after cb7f42e.
在 2023/10/30 18:25, Ozkan Sezer 写道: I have no idea about store apps, sorry. However, maybe something like the following can be done. (Not even compile-tested, and don't know whether it's correct - just showing the idea. Someone more familiar with winstrore should mess with it And also note that clock.c also has a GetModuleHandle use which is not mine..) I'd rather check `_WIN32_WINNT` instead. Windows store apps require Windows 8 (10?) anyway and I hope we can get rid of these initialization-on-demand hacks there. -- Best regards, LIU Hao OpenPGP_signature Description: OpenPGP digital signature ___ 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/8] crt: Move fabsf and nexttowardf to libmsvcr*.a for all archs, and to libucrt*.a for x86
在 2023-10-26 19:15, Martin Storsjö 写道: fabsf is available in UCRT on arm32/arm64, but not on x86. nexttowardf is available in UCRT on all architectures, but this functions takes two parameters, and the second parameter is a long ^ There is a typo in this message. Other than that this series of patches look good to me. -- Best regards, LIU Hao OpenPGP_signature Description: OpenPGP digital signature ___ 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: change LoadLibrary calls to GetModuleHandle after cb7f42e.
在 2023-10-24 22:20, Ozkan Sezer 写道: LoadLibrary needs cleaning after, and we do link to kernel32.dll anyway. This patch looks good to me. Please go ahead and apply. -- Best regards, LIU Hao OpenPGP_signature Description: OpenPGP digital signature ___ 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] Make winpthreads work on Win98
在 2023-10-23 22:05, Christian Franke 写道: +1 from me because this patch also would bring back support for Win XP which (at least) also lacks GetTickCount64(). Currently even a C++ "Hello World!" program using std::cout does not run on Win XP because the C++ exception handling uses this winpthreads module. Thanks for your opinions. I have pushed this patch to master now. -- Best regards, LIU Hao OpenPGP_signature Description: OpenPGP digital signature ___ 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] Make winpthreads work on Win98
在 2023/10/23 15:50, Jonathan Schleifer 写道: Could you please explain why a compile time check would be preferable over a runtime check here? The cost of this runtime check should not be noticeable, most likely not even measurable. Doing runtime check seems extremely common on Windows, and I've seen it all over the place for checking functions that were only introduced in Vista. If you grep MinGW code for GetProcAddr, you'll see it be used plenty, including in libwinpthread in src/clock.c, for example. I'm trying to understand what's the difference in clock.c vs. my patch and why it's acceptable there but not in my patch? Those are probably for hosts that we don't want to drop e.g. Windows 7, 2008, Vista, XP. On the other hand, Windows 98 is way too old and I haven't seen it used anywhere other than some industrial control computers. So this patch adds something that we don't claim to support. Anyway I am not too against this patch if others agree. -- Best regards, LIU Hao OpenPGP_signature Description: OpenPGP digital signature ___ 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] Make winpthreads work on Win98
在 2023/10/21 18:27, Jonathan Schleifer 写道: I really don't see why not to be honest, given how Windows has always maintained forward and backward compatibility. It's not like this patch adds a lot of cost, neither in binary size, nor in code size, nor in maintainability problems. And it's everything that's needed to also make exceptions work on Windows 98, since libgcc_s needs winpthreads. Our decision is that the change shall be within a `#if ...` block. Whether it is ``#if !defined(_WIN32_WINNT)` or `#if _WIN32_WINNT < 0x0500` is questionable, but the patch will not be accepted otherwise. BTW I am also curious: does the CRT work well for you? I thought the Windows 98 MSVCRT.DLL (?) would have lacked some symbols. -- Best regards, LIU Hao OpenPGP_signature Description: OpenPGP digital signature ___ 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: Add missing symbols in ntsecapi.h
在 2023-10-16 02:45, Biswapriyo Nath 写道: From 5958325e235c55288b2a67b924dc5e01cf4613d9 Mon Sep 17 00:00:00 2001 From: Biswapriyo Nath Date: Sun, 15 Oct 2023 18:42:51 + Subject: [PATCH] headers: Add missing symbols in ntsecapi.h Signed-off-by: Biswapriyo Nath --- mingw-w64-headers/include/ntsecapi.h | 131 ++- 1 file changed, 126 insertions(+), 5 deletions(-) Thanks. This patch looks good to me. Pushed to master now. -- Best regards, LIU Hao OpenPGP_signature Description: OpenPGP digital signature ___ 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: Add missing symbols in sspi.h
在 2023-10-14 14:07, Biswapriyo Nath 写道: 0001-headers-Add-missing-symbols-in-sspi.h.patch From 0c2c9cc57d74d6fba9503698c5d0ed808a298acc Mon Sep 17 00:00:00 2001 From: Biswapriyo Nath Date: Sat, 14 Oct 2023 06:06:01 + Subject: [PATCH] headers: Add missing symbols in sspi.h Signed-off-by: Biswapriyo Nath --- mingw-w64-headers/include/sspi.h | 16 1 file changed, 16 insertions(+) Thanks for the patch. Pushed to master now. -- Best regards, LIU Hao OpenPGP_signature Description: OpenPGP digital signature ___ 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: add ADDRINFOEX and LPLOOKUPSERVICE_COMPLETION_ROUTINE to ws2tcpip.h
在 2023-10-13 04:19, Oleg Tolmatcev 写道: Hello, this is needed for pcsx2. Thanks for these patches. Pushed to master now. -- Best regards, LIU Hao OpenPGP_signature Description: OpenPGP digital signature ___ 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: add LPCWAVEFORMATEX in dsound.h
在 2023-10-08 16:53, Oleg Tolmatcev 写道: 0001-headers-add-LPCWAVEFORMATEX-in-dsound.h.txt From 4a3de00359fe96d39df5490b3e7eed046e8bbd11 Mon Sep 17 00:00:00 2001 From: Oleg Tolmatcev Date: Sat, 30 Sep 2023 00:20:13 +0200 Subject: [PATCH] headers: add LPCWAVEFORMATEX in dsound.h --- mingw-w64-headers/include/dsound.h | 5 + 1 file changed, 5 insertions(+) Thanks for the patch. Pushed to master now. -- Best regards, LIU Hao OpenPGP_signature Description: OpenPGP digital signature ___ 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: Add a new PF_* constant to winnt.h
在 2023-10-12 16:26, Martin Storsjö 写道: The constant PF_ARM_V83_LRCPC_INSTRUCTIONS_AVAILABLE was added in winnt.h in upstream WinSDK 10.0.22621.0. Signed-off-by: Martin Storsjö --- mingw-w64-headers/include/winnt.h | 1 + 1 file changed, 1 insertion(+) This patch looks good to me. -- Best regards, LIU Hao OpenPGP_signature Description: OpenPGP digital signature ___ 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: Include more d2d1 headers in uuid library
在 2023-10-06 17:21, Biswapriyo Nath 写道: From cbf1cba09a7807ed4dbbf766f351a848fc836098 Mon Sep 17 00:00:00 2001 From: Biswapriyo Nath Date: Fri, 6 Oct 2023 09:18:59 + Subject: [PATCH] crt: Include more d2d1 headers in uuid library Signed-off-by: Biswapriyo Nath --- mingw-w64-crt/libsrc/uuid.c | 9 + 1 file changed, 9 insertions(+) Thanks for the patch. Pushed to master now. -- Best regards, LIU Hao OpenPGP_signature Description: OpenPGP digital signature ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Mingw-w64 add support for loongarch .
在 2023-10-02 14:46, Biswapriyo Nath 写道: The files in mingw-w64-tools/widl directory are imported from wine project. mingw-w64-tools/widl/wine-import.sh script can help to find which files are imported. So, the patch should be sent to wine project, here https://gitlab.winehq.org/wine/wine For the record, the response was https://gitlab.winehq.org/wine/wine/-/merge_requests/3997 : Alexandre Julliard @julliard There are many more places in widl that assume little-endian, so no, it wouldn't be very useful on a BE system. -- Best regards, LIU Hao OpenPGP_signature Description: OpenPGP digital signature ___ 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: Add uiautomationcore import library
在 2023-10-01 12:10, Biswapriyo Nath 写道:
From 96068175b487ef8b0212b42b1f7e882415576efb Mon Sep 17 00:00:00 2001
From: Biswapriyo Nath
Date: Sun, 1 Oct 2023 04:09:39 +
Subject: [PATCH] crt: Add uiautomationcore import library
Signed-off-by: Biswapriyo Nath
---
.../uiautomationcore.def | 6 +-
mingw-w64-crt/lib32/Makefile.am | 1 +
mingw-w64-crt/lib32/uiautomationcore.def | 106 ++
mingw-w64-crt/lib64/Makefile.am | 1 +
mingw-w64-crt/libarm64/Makefile.am| 1 +
5 files changed, 114 insertions(+), 1 deletion(-)
rename mingw-w64-crt/{libarm32 => lib-common}/uiautomationcore.def (93%)
create mode 100644 mingw-w64-crt/lib32/uiautomationcore.def
Thanks for the patch. Pushed to master now.
--
Best regards,
LIU Hao
OpenPGP_signature
Description: OpenPGP digital signature
___
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: Add an i686 version of api-ms-win-core-registry-l2-1-0.def
在 2023-09-27 20:51, Martin Storsjö 写道: This goes along with the version in lib-common added in f83a1f7d991957d4ee84e1198412a2154084ffe7. The def file is extracted from another (yet unapplied) patch by Steve Lhomme. Signed-off-by: Martin Storsjö --- .../lib32/api-ms-win-core-registry-l2-1-0.def | 31 +++ 1 file changed, 31 insertions(+) create mode 100644 mingw-w64-crt/lib32/api-ms-win-core-registry-l2-1-0.def LGTM, too. -- Best regards, LIU Hao OpenPGP_signature Description: OpenPGP digital signature ___ 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/process: fix bare DllMain/_CRT_INIT signature
在 2023-09-27 20:20, Steve Lhomme 写道: The DWORD reason corresponds to an "unsigned long", not an "unsigned". This is also how it's defined in the Windows SDK. --- mingw-w64-headers/crt/process.h | 8 1 file changed, 4 insertions(+), 4 deletions(-) Thanks for the patch. Pushed to master now. -- Best regards, LIU Hao OpenPGP_signature Description: OpenPGP digital signature ___ 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: Add an i686 version of api-ms-win-security-provider-ansi-l1-1-0.def
在 2023-09-27 20:51, Martin Storsjö 写道: This goes along with the version in lib-common added in b57b0420e16c5811dff576d7fb8932ab871ccf00. The def file is extracted from another (yet unapplied) patch by Steve Lhomme. Signed-off-by: Martin Storsjö --- .../lib32/api-ms-win-security-provider-ansi-l1-1-0.def| 8 1 file changed, 8 insertions(+) create mode 100644 mingw-w64-crt/lib32/api-ms-win-security-provider-ansi-l1-1-0.def This patch looks good to me. -- Best regards, LIU Hao OpenPGP_signature Description: OpenPGP digital signature ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
