Re: [Mingw-w64-public] [PATCH] headers: Add a noreturn attribute on RtlRestoreContext

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. -- Be

Re: [Mingw-w64-public] [PATCH] headers: Add processsnapshot.h

, 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\([^)]+\) +//

Re: [Mingw-w64-public] Consider regenerating autoconf scripts with autoconf 2.72

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

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

Re: [Mingw-w64-public] [PATCH] headers: rename SymRegisterCallback64W to SymRegisterCallbackW64

/_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

Re: [Mingw-w64-public] [PATCH v2 8/8] winpthreads: Use GetModuleHandleA to prevent Unicode errors

+- 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

Re: [Mingw-w64-public] __pformat_fpreg_bits: change to match __gdtoa prototype

f 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-

Re: [Mingw-w64-public] __pformat_fpreg_bits: change to match __gdtoa prototype

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] [PATCH] gendef: Remove printing __DATE__, to improve build reproducibility

mation, 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] strsafe.h cannot be included before windows.h

pString1, 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 Descript

Re: [Mingw-w64-public] [PATCH] Ignore _FORTIFY_SOURCE if __MINGW32__ is not defined

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-p

Re: [Mingw-w64-public] [PATCH] Ignore _FORTIFY_SOURCE if __MINGW32__ is not defined

; 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 sign

Re: [Mingw-w64-public] [PATCH] Ignore _FORTIFY_SOURCE if __MINGW32__ is not defined

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: 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' S

[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

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

Re: [Mingw-w64-public] [PATCH] headers: Move some macros about deprecated functions from 'strsafe.h' into 'dontuse.h'

opyWorkerA_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 0c578c39c17b94af80dcc91b7ae16c46

Re: [Mingw-w64-public] [PATCH] headers: Move some macros about deprecated functions from 'strsafe.h' into '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 signatur

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

Re: [Mingw-w64-public] [PATCH] headers: Move some macros about deprecated functions from 'strsafe.h' into 'dontuse.h'

. 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.

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

Re: [Mingw-w64-public] [PATCH] Use rand_s in mkstemp function

n 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.sourcef

Re: [Mingw-w64-public] [PATCH] crt: Provide fcloseall as alias to _fcloseall

-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

Re: [Mingw-w64-public] [PATCH v2] crt: Use rand_s in the mkstemp function

/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-p

Re: [Mingw-w64-public] [PATCH 1/3] crt: Add non-inline variant of UCRT _scprintf, _snprintf and _snscanf functions

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 1/3] crt: Add non-inline variant of UCRT _scprintf, _snprintf and _snscanf functions

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-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.

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

Re: [Mingw-w64-public] [PATCH 1/3] crt: Add non-inline variant of UCRT _scprintf, _snprintf and _snscanf functions

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

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

Re: [Mingw-w64-public] [PATCH] crt: Cleanup _scprintf/_vscprintf for non-msvcrtos builds

--- 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

Re: [Mingw-w64-public] [PATCH] crt: Do not depend on _strtoi64/_strtoui64 symbols for I386 msvcrt.dll

-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

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

Re: [Mingw-w64-public] Relocation errors when linking with static libstdc++ starting with GCC 6 (64-bit only)

On 2017/2/8 1:45, Ricardo Constantino wrote: > Should be fixed with > https://github.com/Alexpux/MINGW-packages/commit/ba282a67e, but I thought > someone would've reported it to upstream by now? Probably you could comment this PR https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69506. -- Best regard

Re: [Mingw-w64-public] [PATCH] Align thread entry point stack

On 2017/3/8 4:31, Mateusz Mikuła wrote: > Forwarding Aleksey's message from MSYS2 discussion: > [...] > W dniu 22.01.2017 o 11:36, Adrien Nader pisze: >> Hi, >> >> I've recently re-stumbled upon this. As far as I can tell it hasn't been >> commited. Was there some more discussion on the topic or di

[Mingw-w64-public] [PATCH] winreg.h: Fix declaration of RegSetKeyValueW

janisozaur on IRC reported a bug about `RegSetKeyValueW()` today. According to MSDN the parameters `lpSubKey` and `lpValueName` of `RegSetKeyValue()` should have type `LPCTSTR`, hence in the case of `RegSetKeyValueW()` they should have type `LPCWSTR`. In our headers they used to have type `LPCS

Re: [Mingw-w64-public] [PATCH] Align thread entry point stack

On 2017/3/8 11:27, Liu Hao wrote: On 2017/3/8 4:31, Mateusz Mikuła wrote: Forwarding Aleksey's message from MSYS2 discussion: [...] W dniu 22.01.2017 o 11:36, Adrien Nader pisze: Hi, I've recently re-stumbled upon this. As far as I can tell it hasn't been commited. Was

[Mingw-w64-public] [PATCH 2/2] winpthreads/src/thread.c: Fix SetThreadName().

From c2f24277dbc6878b98a5f5174a01b103d16d5bcd Mon Sep 17 00:00:00 2001 From: Liu Hao Date: Fri, 10 Mar 2017 15:49:35 +0800 Subject: [PATCH 2/2] winpthreads/src/thread.c: Fix SetThreadName(). MSDN says the struct should be passed in as an array of ULONG_PTRs. Don't use plain DWORD sin

Re: [Mingw-w64-public] mkdir and MINGW_ATTRIB_DEPRECATED_MSVC2005

On 2017/3/11 10:22, sisyph...@optusnet.com.au wrote: > So ... how do I see the associated "deprecation" warning when compiling a > program that contains a call to "mkdir" ? The warning is enabled by adding `#define __MINGW_MSVC_COMPAT_WARNINGS 1` before #include'ing any headers or use the command-

Re: [Mingw-w64-public] Erroneous "out of memory" using LTO

On 2017/3/13 20:17, Riot wrote: > I have tried replacing -flto with -whopr as suggested at > https://sourceforge.net/p/mingw-w64/wiki2/LTO%20and%20GCC/, but this is now > an unrecognised commandline option. Try `-fwhole-program`. -- Best regards, LH_Mouse ---

Re: [Mingw-w64-public] [PATCH] Align thread entry point stack

On 2017/3/10 15:41, Liu Hao wrote: > On 2017/3/8 11:27, Liu Hao wrote: >> On 2017/3/8 4:31, Mateusz Mikuła wrote: >>> Forwarding Aleksey's message from MSYS2 discussion: >>> [...] >>> W dniu 22.01.2017 o 11:36, Adrien Nader pisze: >>>> Hi, >&

Re: [Mingw-w64-public] Fwd: Fix for winreg.h

On 2017/3/14 18:57, JonY wrote: > Looks like LH has already applied this to master. Yes I pushed it a couple of days ago. He said his mails were suspended on this ML (and it seemed so). Best regards, LH_Mouse -- Check o

Re: [Mingw-w64-public] [PATCH] pdh.h: use PDH_FUNCTION for Vista+ functions

On 2017/3/16 5:26, Jon Turney wrote: > Use PDH_FUNCTION rather than just PDH_STATUS, so these functions are > correctly decorated with WINAPI (= stdcall on x86), so linkage works > correctly on x86. This is indeed how Microsoft people declare these functions. Is this patch ok to apply? However, un

Re: [Mingw-w64-public] [PATCH] pdh.h: use PDH_FUNCTION for Vista+ functions

On 2017/3/16 13:20, Ozkan Sezer wrote: > On 3/16/17, Liu Hao wrote: >> On 2017/3/16 5:26, Jon Turney wrote: >>> Use PDH_FUNCTION rather than just PDH_STATUS, so these functions are >>> correctly decorated with WINAPI (= stdcall on x86), so linkage works >>> cor

Re: [Mingw-w64-public] [PATCH] Use LPCVOID instead of 'const LPVOID' for VerQueryValue

On 2017/3/17 0:51, David Grayson wrote: > I was trying to compile Qt and I ran into an error because Qt is > passing a const pointer to the first argument of VerQueryValue, which > is not properly marked as const in the mingw-w64 header files. This > patch fixes that. Please send the patch both in

Re: [Mingw-w64-public] [PATCH] (again) Use LPCVOID instead of 'const LPVOID' for VerQueryValue.

On 2017/3/17 11:09, David Grayson wrote: > Here is that patch again. Thanks! These new prototypes match https://msdn.microsoft.com/en-us/library/windows/desktop/ms647464.aspx , so I think it is ok to apply, no? -- Best regards, LH_Mouse ---

Re: [Mingw-w64-public] [PATCH] (again) Use LPCVOID instead of 'const LPVOID' for VerQueryValue.

On 2017/3/17 17:43, Kai Tietz wrote: > Ok for master. Thanks for the review. Pushed to master. -- Best regards, LH_Mouse -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.o

Re: [Mingw-w64-public] [PATCH] Use LPCVOID instead of 'const LPVOID' for VerQueryValue

On 2017/3/20 22:34, Mateusz Mikuła wrote: > It explains why my patches created with `git format-patch` couldn't > make it. > > Their mime type is `text/x-diff`. Isn't it our mail clients that guess MIME types of attachments? The diff file doesn't have any MIME type information stored with it. --

Re: [Mingw-w64-public] [PATCH] Add DBG_PRINTEXCEPTION_WIDE_C exception

On 2017/3/20 20:49, Jon Turney wrote: > Windows 10 now has a separate exception for OutputDebugStringW, rather than > converting the string to ANSI and raising DBG_PRINTEXCEPTION_C. > > (See > https://ntquery.wordpress.com/2015/09/07/windows-10-new-anti-debug-outputdebugstringw/) It can also be fo

Re: [Mingw-w64-public] [PATCH] Update definitions in 64bit ntdll.def to match the 32bit one.

On 2017/3/21 15:20, Tamar Christina wrote: > As discussed on IRC this patch will normalise the behavior between the 32bit > and the 64bit > ntdll.def file so that both have the same definitions as DATA. The attachment seems swallowed again. -- Best regards, LH_Mouse ---

Re: [Mingw-w64-public] [PATCH] Use LPCVOID instead of 'const LPVOID' for VerQueryValue

On 2017/3/22 4:57, Mateusz Mikuła wrote: > Sorry for the delay but I spent almost whole day in college. > > Thank you for adding it, here comes small patch to test it. I got the attachment but its Content-Type said plain text. Is this normal behavior? * * * * * Content-Type: text/plain; charset=

Re: [Mingw-w64-public] [PATCH] Add DBG_PRINTEXCEPTION_WIDE_C exception

On 2017/3/22 3:59, Jon Turney wrote: > On 21/03/2017 07:43, Ruben Van Boxem wrote: > This value is not guarded in that way in the SDK. I'm not sure why that > might be. I am ok with it if JonY or Kai says it is. -- Best regards, LH_Mouse

Re: [Mingw-w64-public] [PATCH] Add DBG_PRINTEXCEPTION_WIDE_C exception

On 2017/3/22 20:46, JonY wrote: > On 03/22/2017 10:39 AM, Liu Hao wrote: >> On 2017/3/22 3:59, Jon Turney wrote: >>> On 21/03/2017 07:43, Ruben Van Boxem wrote: >>> This value is not guarded in that way in the SDK. I'm not sure why that >>> might be. >

Re: [Mingw-w64-public] bug in mingw-w64 tanh()

he fact that both can be NaNs we can replace it with `tanh(2 * __real__ z)` directly ({sin,cos,tan}h functions are part of MSVCRT). The attached patch should fix the problem. I am not a mathematician, though. So please correct me. -- Best regards, LH_Mouse From a46cc6ea45467cad2b0669417

Re: [Mingw-w64-public] bug in mingw-w64 tanh()

On 2017/3/24 23:58, Liu Hao wrote: > On 2017/3/24 23:08, Jeroen Ooms wrote: >> I was able to reproduce the problem on msys2 with gcc 6.3: >> >> #include >> #include >> #include >> >> int main(){ >> std::cout << std::fixed;

Re: [Mingw-w64-public] [PATCH] strsafe.h: Change __inline to __CRT_INLINE

patch for this issue. Please test. -- Best regards, LH_Mouse From f2f652c023ad1320f69bd7d5f0d5c47376056869 Mon Sep 17 00:00:00 2001 From: Liu Hao Date: Mon, 3 Apr 2017 02:00:15 +0800 Subject: [PATCH] include/strsafe.h: Fix warning 'inline function declared but never defined'.

Re: [Mingw-w64-public] [PATCH] strsafe.h: Change __inline to __CRT_INLINE

clared as inline in this case. That is why my previous patch failed. Apologies for that. New patch attached. -- Best regards, LH_Mouse From f1c12fd9f35525ca3569c3427f953afb10b47588 Mon Sep 17 00:00:00 2001 From: Liu Hao Date: Mon, 3 Apr 2017 02:00:15 +0800 Subject: [PATCH] include/strsafe.h

Re: [Mingw-w64-public] [PATCH] strsafe.h: Change __inline to __CRT_INLINE

On 2017/4/4 0:48, David Grayson wrote: > I'm a bit confused about the different inlining keywords. From the GCC > documentation for inlining in the C language ( > https://gcc.gnu.org/onlinedocs/gcc/Inline.html ) it seemed like "extern > inline" (i.e. __CRT_INLINE) would be the best thing to use, b

Re: [Mingw-w64-public] [PATCH] strsafe.h: Change __inline to __CRT_INLINE

On 2017/4/4 2:11, Jacek Caban wrote: > I'm sorry to jump into discussion so late. The patch looks good to me. OK I pushed it to master. -- Best regards, LH_Mouse -- Check out the vibrant tech community on one of the wor

Re: [Mingw-w64-public] [PATCH] strsafe.h: Change __inline to __CRT_INLINE

On 2017/4/4 1:19, David Grayson wrote: > What you say matches what I got from my experiments, but it's odd that it > doesn't match the GCC documentation I linked to, which says: > > If you specify both inline and extern in the function definition, then > the definition is used only for inlining.

Re: [Mingw-w64-public] [PATCH] Implement some Secure Template Overloads

On 2017/4/5 3:59, Tamir Duberstein wrote: > Jacek, it doesn't look like this was pushed, or at least I don't see > the change in https://sourceforge.net/p/mingw-w64/mingw-w64/ci/v5.x/tree/. > Could you verify? It seems Jon didn't push that branch. -- Best regards, LH_Mouse -

Re: [Mingw-w64-public] [PATCH] stralign: cast ua_wcschr and ua_wcsrchr returns to wchar_t *

On 2017/4/5 21:51, Mateusz Mikuła wrote: > Conversion from const pointer to normal pointer is definitely unsafe but > that's probably what GCC just did. > I'm unsure what you mean by "union-cast" but you can commit your fix. Take a look at the prototype of the `strchr` function in the C standard l

Re: [Mingw-w64-public] [PATCH] stralign: cast ua_wcschr and ua_wcsrchr returns to wchar_t *

On 2017/4/6 20:47, Kai Tietz wrote: > True. The reason why we prefer such patter is that it works in both > languages as desired. Otherwise we would be in need to write > different variants for the languages C/C++. This looks backward, and > it still doesn't make sure that there might be warning

Re: [Mingw-w64-public] Problem using gcc in MSYS2 shell

On 2017/4/7 0:56, Edward Diener wrote: > When trying to compile a project in MSYS2 using mingw-64/gcc I get this > error: > (... abridgement ...) This was an oversight. I replied with detailed information on msys2-users. -- Best regards, LH_Mouse

Re: [Mingw-w64-public] [PATCH] stralign: cast ua_wcschr and ua_wcsrchr returns to wchar_t *

On 2017/4/7 8:11, Norbert Pfeiler wrote: > Wasn’t LH_Mouse’s point that even if the warning is explicitly turned on it > wouldn’t be shown to the user? > > The situation for unions is different in C and C++: (I don’t think that > it’s just about constness changes anything) > http://stackoverflow.co

Re: [Mingw-w64-public] [PATCH] stralign: cast ua_wcschr and ua_wcsrchr returns to wchar_t *

On 2017/4/8 1:00, David Grayson wrote: > I did read the top two answers in the link that Norbert posted: > > http://stackoverflow.com/questions/11373203/accessing-inactive-union-member-and-undefined-behavior > > The first answer (from ecatmur) indicates that this kind of conversion with > a union w

Re: [Mingw-w64-public] Using mcfgthread instead of the gcc thread library

On 2017/4/9 8:12, Edward Diener wrote: > 1) if mcfgthread replaces the mingw-64/gcc-6.3 threading library when used. It takes the place of winpthreads completely. > 2) if it replaces the mingw-64/gcc-6.3 threading library even when I had > installed mingw-64/gcc-6.3 with posix threading support as

Re: [Mingw-w64-public] Using mcfgthread instead of the gcc thread library

On 2017/4/9 22:59, Edward Diener wrote: > Are you saying that I have to build gcc-6.3 myself on Windows, rather > than juat install it from mingw-w64-install, in order to use your library ? Yes. However I also build it constantly, which is available here: . These fil

Re: [Mingw-w64-public] Using mcfgthread instead of the gcc thread library

On 2017/4/10 10:04, Edward Diener wrote: > Thanks for the link. I am curious though why you could not have supplied > alternative versions of the mingw-64/gcc threading library rather than > entirely new builds of mingw-64/gcc ? Did you actually have to modify > other modules of mingw-64/gcc to get

Re: [Mingw-w64-public] [PATCH] usbspec.h: Add some missing structs and definitions.

On 2017/4/18 0:47, David Grayson wrote: > Hello. The attached patch adds some definitions and structs that were > missing from usbspec.h. I needed this to build the latest version of > Microsoft's usbview program ( > https://github.com/DavidEGrayson/nixcrpkgs/tree/master/pkgs/usbview ). It looks

Re: [Mingw-w64-public] [PATCH] usbspec.h: Add some missing structs and definitions.

On 2017/4/18 0:47, David Grayson wrote: > Hello. The attached patch adds some definitions and structs that were > missing from usbspec.h. I needed this to build the latest version of > Microsoft's usbview program ( > https://github.com/DavidEGrayson/nixcrpkgs/tree/master/pkgs/usbview ). I checked

Re: [Mingw-w64-public] [PATCH] Add ShutdownBlockReason* to lib64/user32.def

On 2017/4/22 6:32, Aman Gupta wrote: > From: Aman Gupta > > These are already included as part of lib32/user32.def > > Fixes https://sourceforge.net/p/mingw-w64/bugs/526/ This looks reasonable to me. I may commit it a few hours later. -- Best regards, LH_Mouse -

Re: [Mingw-w64-public] [PATCH] Update 64bit user32.def

On 2017/4/22 10:35, JonY wrote: > Patch OK for master? Oh well this supersedes the previous patch. -- Best regards, LH_Mouse -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashd

Re: [Mingw-w64-public] GUID definition in guiddef.h

On 2017/4/28 19:38, Vincent Torri wrote: > Hello > > in guiddef.h, a GUID is a struct organized as : 4 bytes, 2 bytes 2 > bytes and 8 times 1 byte > > but according to > https://msdn.microsoft.com/en-us/library/dd354925.aspx at the bottom : > > "The correct format of the GUID string is > {CDEF7890-

Re: [Mingw-w64-public] GUID definition in guiddef.h

On 2017/4/28 21:38, Vincent Torri wrote: > ok, the MSDC doc i mentioned is incorrect... > > thank you My pleasure. Nevertheless it isn't being incorrect at all. It is just the doc about the human readable format and is irrelevant to the binary representation. -- Best regards, LH_Mouse ---

Re: [Mingw-w64-public] Duplicate symbols definition in between uuid.c and extra-uuid.c

On 2017/5/1 21:27, Tomay wrote: > The following UUIDs are defined in both *uuid.c* and *extra-uuid.c* source > files, whitch leads to linking errors with duplicate symbols when using > *libuuid.a* > In my opinion it is practically incorrect, but you shouldn't get linker errors because the macro `I

Re: [Mingw-w64-public] Duplicate symbols definition in between uuid.c and extra-uuid.c

On 2017/5/2 3:08, David Grayson wrote: > Oops, I should have learned my lesson. Well, here it is again. I think my > original email 6 days ago was good though. I did see the patch and we had a discussion on irc. That attribute seemed to have been removed for a reason, which otherwise caused erro

Re: [Mingw-w64-public] Duplicate symbols definition in between uuid.c and extra-uuid.c

On 2017/5/2 12:04, David Grayson wrote: > Thanks for the info. > > I used "git blame" on guiddef.h and it looks like the logic has been the > same since 2007. I don't see any sign that Kai removed the > DECLSPEC_SELECTANY from the GUID declarations, as far as I know it was just > always missing. >

Re: [Mingw-w64-public] [PATCH] guiddef.h: Use __declspec(selectany) on GUID declarations.

Kai, did you mean this patch was ok for master? -- Best regards, LH_Mouse -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot __

Re: [Mingw-w64-public] [PATCH] guiddef.h: Use __declspec(selectany) on GUID declarations.

On 2017/5/2 18:38, Kai Tietz wrote: > I think, it is worth a try. In general it looks sensible. As you wish. -- Best regards, LH_Mouse -- Check out the vibrant tech community on one of the world's most engaging tech si

Re: [Mingw-w64-public] [PATCH] guiddef.h: Use __declspec(selectany) on GUID declarations.

On 2017/5/3 6:23, Mateusz wrote: > W dniu 2017-05-02 o 13:08, Liu Hao pisze: >> On 2017/5/2 18:38, Kai Tietz wrote: >>> I think, it is worth a try. In general it looks sensible. >> As you wish. > > For GCC 7.1 and 6.3 the patch is OK. > > For GCC 5.4 is

Re: [Mingw-w64-public] [PATCH] guiddef.h: Use __declspec(selectany) on GUID declarations.

On 2017/5/3 9:33, Liu Hao wrote: > Kai, should we revert it? We have to deal with the multiple definition > error thereafter. > A number of UUIDs/GUIDs are suffering from such multiple definitions, which can be discovered using the following commands: ```bash grep -EhrI '^DEFINE

Re: [Mingw-w64-public] [PATCH] guiddef.h: Use __declspec(selectany) on GUID declarations.

On 2017/5/3 12:46, David Grayson wrote: > I won't be offended if you revert it. I reverted it and added a line of comment explaining what had happened. > I'm not sure what your shell commands do, but as long as there is one GUID > defined in one header file, and the selectany attribute is not used

Re: [Mingw-w64-public] winpthreads and gcc 7.1

On 2017/5/3 15:35, Christer Solskogen wrote: I'm having a hard time (cross) compiling winpthreads (from 5.x branch) with gcc 7.1. Please try the attached patch. -- Best regards, LH_Mouse From 4fa48b2af092a3b8615cef39b6e0036e20481c3f Mon Sep 17 00:00:00 2001 From: Liu Hao Date: Wed,

[Mingw-w64-public] Successful bootstrap of GCC 7.1.1 targeting {i686, x86_64}-w64-mingw32 with MCF thread model

Hello all, This message indicates success of bootstrapping GCC 7.1.1 on i686-w64-mingw32 and x86_64-w64-mingw32 with MCF thread model. You may get prebuilt binaries at . Special thanks to MSYS2 for the gcc-git package, which this work is largely based on. Both of

Re: [Mingw-w64-public] winpthreads and gcc 7.1

On 2017/5/3 18:56, Christer Solskogen wrote: > On 03.05.2017 10.23, Liu Hao wrote: >> On 2017/5/3 15:35, Christer Solskogen wrote: >>> I'm having a hard time (cross) compiling winpthreads (from 5.x branch) >>> with gcc 7.1. >> Please try the attached patc

Re: [Mingw-w64-public] [PATCH] guiddef.h: Use __declspec(selectany) on GUID declarations.

On 2017/5/3 23:12, David Grayson wrote: > When you say "optimal", what are you optimizing for? > For decreasing object file sizes and link time, apparently. > The UsbView code uses that header file in several different translation > units, so you end up having a bunch of duplicate GUID definitions

Re: [Mingw-w64-public] winpthreads and gcc 7.1

On 2017/5/4 13:54, Daniel Santos wrote: > I see one in libgcc, but I guess you would have to add that to your > link. I presume it's in the dynamic portion. As Kai said yesterday on IRC, in the case of cross compiling libpthread has to be available prior to libgcc. That is the reason why we link

Re: [Mingw-w64-public] About Multiversion

On 2017/5/5 23:44, Tony Zhao wrote: > Hello there!I'm a senior high school student in China. I am a member > preparing for the Olympiad in Informatics using your Mingw-w64. It's nice > however around us there are two main G++s:4.8.4 which is used in our Online > Judge system and in the competiti

[Mingw-w64-public] Implement weak __divmoddi4() and __udivmoddi4() for internal use by the CRT and winpthreads?

Hello all, Since GCC 7, a new function `__divmoddi4()` is added in libgcc. When GCC performs division of two 64-bit integers on i686, a call to this function is emitted, which could result in undefined references to this function when we are building part of the CRT (winpthreads for example,

[Mingw-w64-public] [PATCH] winpthreads/src/dll_math.c: Implement `__divmoddi4()' for GCC 7.

or it. Please review. (I really hate this C-ish code but this way it looks like how `__udivdi3` was implemented.) -- Best regards, LH_Mouse From 04f0579cb7e2f294e1e3ad2be18b8d059546208f Mon Sep 17 00:00:00 2001 From: Liu Hao Date: Wed, 3 May 2017 15:52:32 +0800 Subject: [PATCH] winpth

Re: [Mingw-w64-public] [PATCH] Include driverspecs.h in specstrings.h.

On 2017/5/10 10:34, David Grayson wrote: > This patch adds "#include " near the end of specstrings.h, > because the same is done in Microsoft's version of specstrings.h. With > this patch, I am able to build Microsoft's devcon utility without > modification. Thanks! You must `#include` that heade

Re: [Mingw-w64-public] [PATCH] Include driverspecs.h in specstrings.h.

On 2017/5/10 23:24, David Grayson wrote: > OK, thanks. I've attached a new patch where the #include is after the > __cplusplus stuff. > > I also included a second patch that will add an include guard for > specstrings.h, since Microsoft seems to do that too. > > driverspecs.h is also missing a

[Mingw-w64-public] Fwd: Re: [PATCH] Include driverspecs.h in specstrings.h.

Forwarded Message Subject: Re: [Mingw-w64-public] [PATCH] Include driverspecs.h in specstrings.h. Date: Wed, 10 May 2017 08:24:25 -0700 From: David Grayson To: Liu Hao OK, thanks. I've attached a new patch where the #include is after the __cplusplus

Re: [Mingw-w64-public] Fwd: Re: [PATCH] Include driverspecs.h in specstrings.h.

On 2017/5/11 21:51, David Grayson wrote: > Unfortunately, my patch seems to break several classes in libstdc++, > preventing Qt from building. The problem is that driverspecs.h defines > __in to be empty so we can compile Microsoft-type code that uses __in as a > source annotation on function para

Re: [Mingw-w64-public] Fwd: Re: [PATCH] Include driverspecs.h in specstrings.h.

On 2017/5/11 23:11, Kai Tietz wrote: > I would prefer this too, but I don't believe that we can convince > libstdc++ maintainers to modify their code for this. Sadly the MS' > platform sdk defines a lot of stuff, which collides some times with > some projects. We made about this already a lot of

Re: [Mingw-w64-public] __builtin_isnanl() and invalid x87 80-bit floating point numbers

On 2017/5/16 0:43, Vincent Lefevre wrote: > On 2017-05-15 22:35:33 +0800, Liu Hao wrote: >> Yeah but `printf()` from glibc doesn't think it is a NaN... From >> your point of view, is this a glibc bug? > > I think so. If I understand correctly, the output of floatin

Re: [Mingw-w64-public] Fwd: Re: [PATCH] Include driverspecs.h in specstrings.h.

On 2017/5/16 17:35, Jonathan Wakely wrote: > On 11 May 2017 at 17:55, David Grayson wrote: >> Hello, gcc-help. >> >> There is an incompatibility between libstdc++ and the headers provided >> by Microsoft and mingw-w64, because libstdc++ uses __in as a parameter >> name in several places while the M

Re: [Mingw-w64-public] Fwd: Re: [PATCH] Include driverspecs.h in specstrings.h.

On 2017/5/16 18:09, Jonathan Wakely wrote: > Hmm, if it's not defined when compiling with GCC then where does the > conflict come from? > These macros weren't there until recently because of the feature request by David Grayson. They don't exist in any release versions of MinGW-w64 so there is n

<    2   3   4   5   6   7   8   9   10   11   >