Re: [Mingw-w64-public] [PATCH v2 1/4] headers: Implement the __fastfail intrinsic

Thanks! Do you also need to add the prototype of __fastfail to intrin.h? Also, there is a TODO comment in winnt.h about __fastfail, which I guess should be made obsolete by this patch, is this right? On 22/9/2022 0:01, Martin Storsjö wrote: > Signed-off-by: Martin Storsjö > --- > mingw-w64-hea

Re: [Mingw-w64-public] [PATCH v3] crt: Add support for Control Flow Guard

Cheers, I will get to the changes on the llvm-mingw side soon. On 26/9/2022 15:30, Martin Storsjö wrote: > On Thu, 22 Sep 2022, Martin Storsjö wrote: > >> On Thu, 22 Sep 2022, Alvin Wong via Mingw-w64-public wrote: >> >>> This adds support to enable building mingw

Re: [Mingw-w64-public] [PATCH v2 3/4] crt: Provide the stack protector functions/variables in libmingwex too

On 22/9/2022 0:01, Martin Storsjö wrote: > +static void __cdecl __attribute__((__constructor__)) init(void) > +{ > + HCRYPTPROV crypt = 0; > + if (__stack_chk_guard != 0) > +return; > + > + if (CryptAcquireContext(&crypt, NULL, NULL, PROV_RSA_FULL, > CRYPT_VERIFYCONTEXT | CRYPT_SILENT)) { >

Re: [Mingw-w64-public] [PATCH v3 09/10] RFC: crt: Try using BCrypt and RtlGenRandom before rand_s for initializing __stack_chk_guard

On 30/9/2022 5:25, Martin Storsjö wrote: > + bcrypt = LoadLibraryW(L"bcrypt.dll"); > + if (bcrypt) { > +NTSTATUS (WINAPI *pBCryptOpenAlgorithmProvider)(BCRYPT_ALG_HANDLE *, > LPCWSTR, LPCWSTR, ULONG); > +NTSTATUS (WINAPI *pBCryptGenRandom)(BCRYPT_ALG_HANDLE, PUCHAR, ULONG, > ULONG); > +

[Mingw-w64-public] [PATCH] crt: Move xmllite to lib-common

Signed-off-by: Alvin Wong --- Quick-tested on x86 and x64. mingw-w64-crt/{libarm32 => lib-common}/xmllite.def | 2 +- mingw-w64-crt/lib32/Makefile.am| 1 + mingw-w64-crt/lib32/xmllite.def| 13 + mingw-w64-crt/lib64/Makefile.am

[Mingw-w64-public] [PATCH 3/3] headers: Declare UUID for IContextCallback

This is needed for `__uuidof(IContextCallback)` to work. --- mingw-w64-headers/include/ctxtcall.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/mingw-w64-headers/include/ctxtcall.h b/mingw-w64-headers/include/ctxtcall.h index 9fa8ec41e..65162f33f 100644 --- a/mingw-w64-headers/include/ct

[Mingw-w64-public] [PATCH 2/3] headers: Add declaration of CLSID_ContextSwitcher

--- mingw-w64-headers/include/cguid.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/mingw-w64-headers/include/cguid.h b/mingw-w64-headers/include/cguid.h index 497c4c5b7..0ded4b743 100644 --- a/mingw-w64-headers/include/cguid.h +++ b/mingw-w64-headers/include/cguid.h @@ -91,6 +91,8 @@ ext

[Mingw-w64-public] [PATCH 1/3] crt: Add CLSID and IIDs for IContextCallback

Define the following GUIDs in libuuid.a: * IID_IContextCallback * IID_ICallbackWithNoReentrancyToApplicationSTA * IID_IEnterActivityWithNoLock * CLSID_ContextSwitcher --- mingw-w64-crt/Makefile.am| 1 + mingw-w64-crt/libsrc/ctxtcall-uuid.c | 18 ++ 2 files changed, 19

Re: [Mingw-w64-public] [PATCH 3/3] headers: Declare UUID for IContextCallback

Wine does seem to have ctxtcall.idl, but I'm not familiar with the procedure of importing IDL files from Wine. Also, the current ctxtcall.h in mingw-w64 seems to have some extra declarations which I'm not sure of. I suspect it may take a bit of effort to replace ours with the one from Wine, wh

Re: [Mingw-w64-public] [PATCH 3/3] headers: Declare UUID for IContextCallback

Thanks for importing the IDL from Wine! The patch 3/3 can be skipped now. On 15/10/2022 1:51, Biswapriyo Nath wrote: Would it be better if IDL file is provided instead of writing header file manually? ___ Mingw-w64-public mailing list Mingw-w64-publ

[Mingw-w64-public] [PATCH] headers: Add windowsnumerics.h, windowsnumerics.impl.h

These headers are only partially implemented. They include all the type definitions and struct members according to the docs. All the functions have been declared but not all of them are defined. Attempting to use the undefined functions will likely produce a compiler warning followed by a linker

Re: [Mingw-w64-public] [PATCH 1/1] crt/stdlib: Add missing _strtof_l function and redirections

Thanks for the patch :) On 2/11/2022 6:48, L. E. Segovia via Mingw-w64-public wrote: diff --git a/mingw-w64-headers/crt/tchar.h b/mingw-w64-headers/crt/tchar.h index 9fa2a030..5ae9479c 100644 --- a/mingw-w64-headers/crt/tchar.h +++ b/mingw-w64-headers/crt/tchar.h @@ -209,6 +209,7 @@ extern "C" {

[Mingw-w64-public] [PATCH] crt/ssp: Use different __fastfail code in __chk_fail

Make __chk_fail use FAST_FAIL_RANGE_CHECK_FAILURE instead of FAST_FAIL_STACK_COOKIE_CHECK_FAILURE to distinguish from __stack_chk_fail. Signed-off-by: Alvin Wong --- mingw-w64-crt/ssp/chk_fail.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mingw-w64-crt/ssp/chk_fail.c b/mi

Re: [Mingw-w64-public] [PATCH] headers: Add windowsnumerics.h, windowsnumerics.impl.h

On 6/11/2022 5:20, Martin Storsjö wrote: On Fri, 21 Oct 2022, Alvin Wong via Mingw-w64-public wrote: These headers are only partially implemented. They include all the type definitions and struct members according to the docs. All the functions have been declared but not all of them are

Re: [Mingw-w64-public] [PATCH] headers: Add windowsnumerics.h, windowsnumerics.impl.h

On 7/11/2022 4:41, Martin Storsjö wrote: On Sun, 6 Nov 2022, Alvin Wong wrote: On 6/11/2022 5:20, Martin Storsjö wrote: On Fri, 21 Oct 2022, Alvin Wong via Mingw-w64-public wrote: About the WinRT interop functions - how are they supposed to be provided? This header is layered under the C

[Mingw-w64-public] [PATCH v2] headers: Add windowsnumerics.h, windowsnumerics.impl.h

v2: - Fixed whitespace - Added implementation for a few more functions and added simple test cases for them - Removed unused C++/CX interop functions From 0afef3733674c7f7bdde54813f9c5b39276d Mon Sep 17 00:00:00 2001 From: Alvin Wong Date: Thu, 20 Oct 2022 23:15:47 +0800 Subject: [PATCH]

[Mingw-w64-public] [PATCH] headers/shlobj.h: Add missing KNOWN_FOLDER_FLAG constants

Signed-off-by: Alvin Wong --- The docs states that the preexisting KF_FLAG_NO_APPCONTAINER_REDIRECTION constant was introduced in win8, but the current version guard checks for win7 instead. I left it as is. mingw-w64-headers/include/shlobj.h | 11 +++ 1 file changed, 11 insertions(+) d

Re: [Mingw-w64-public] [PATCH] headers: Implement quaternion functions in windowsnumerics.h

On 22/11/2022 20:07, Martin Storsjö wrote: + inline bool decompose(const float4x4 &mat, float3 *out_scale, quaternion *out_rot, float3 *out_translate) { +float4x4 val = mat; +if (out_translate) + *out_translate = translation(val); +val.m41 = val.m42 = val.m43 = 0.0f; +float

Re: [Mingw-w64-public] [PATCH v3] headers: Implement quaternion functions in windowsnumerics.h

Thanks, looks good to me. On 25/11/2022 5:25, Martin Storsjö wrote: Also implement a couple make_float4x4_* functions that are useful for constructing input for some tests. This reduces the number of unimplemented functions in this header a little bit. Signed-off-by: Martin Storsjö --- v3: L

Re: [Mingw-w64-public] Mingw-w64 add support for riscv64?

Hi, From my understanding, `mingw-w64-tools/widl` is imported from Wine, so any changes should be submitted to the other upstream: https://gitlab.winehq.org/wine/wine/-/blob/master/include/basetsd.h Cheers, Alvin On 13/12/2022 16:08, Bo YU wrote: Hi, I asked about the possibility on IRC ab

Re: [Mingw-w64-public] Mingw-w64 add support for riscv64?

of Windows for riscv, I don't think there is anything for us to do in this regard. Cheers, Alvin On 13/12/2022 16:41, Bo YU wrote: hi Alvin, On Tue, Dec 13, 2022 at 4:30 PM Alvin Wong via Mingw-w64-public wrote: Hi, From my understanding, `mingw-w64-tools/widl` is imported from Win

[Mingw-w64-public] [PATCH] headers: Add systemmediatransportcontrolsinterop.idl

Signed-off-by: Alvin Wong --- mingw-w64-headers/Makefile.am | 1 + .../systemmediatransportcontrolsinterop.idl | 15 +++ 2 files changed, 16 insertions(+) create mode 100644 mingw-w64-headers/include/systemmediatransportcontrolsinterop.idl diff --git a/mi

Re: [Mingw-w64-public] interface macro conflicts with interface variable

On 21/12/2022 16:45, LIU Hao wrote: If you define `WIN32_LEAN_AND_MEAN` (either `#define` it or pass `-DWIN32_LEAN_AND_MEAN` to GCC) before inclusion of , then the error will go away. This seems to be yet another reason why `WIN32_LEAN_AND_MEAN` should be preferred. ...which only works if yo

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

Signed-off-by: Alvin Wong --- Added according to https://learn.microsoft.com/en-us/windows/win32/api/shcore/. These functions are used for WinRT interop with IStream. mingw-w64-headers/include/shcore.h | 33 ++ 1 file changed, 33 insertions(+) create mode 100644 ming

[Mingw-w64-public] [RFC PATCH] headers: Add robuffer.idl to generate robuffer.h

Signed-off-by: Alvin Wong --- Implemented according to https://learn.microsoft.com/en-us/windows/win32/api/robuffer/. This file defines the Windows::Storage::Streams::IBufferByteAccess interface which implementors of (ABI::)Windows::Storage::Streams::IBuffer must also implement. The Windows SDK d

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

On 26/12/2022 8:45, JonY via Mingw-w64-public wrote: On 12/25/22 14:53, Alvin Wong via Mingw-w64-public wrote: Signed-off-by: Alvin Wong --- Added according to https://learn.microsoft.com/en-us/windows/win32/api/shcore/. These functions are used for WinRT interop with IStream.   mingw-w64

[Mingw-w64-public] [PATCH v2] headers: Add shcore.h

Signed-off-by: Alvin Wong --- Removed trailing comma after last enum item. mingw-w64-headers/include/shcore.h | 33 ++ 1 file changed, 33 insertions(+) create mode 100644 mingw-w64-headers/include/shcore.h diff --git a/mingw-w64-headers/include/shcore.h b/mingw-w64

Re: [Mingw-w64-public] New Direct-Storage APIs in the MinGW-W64 toolchain

Hi, It looks like the DirectStorage SDK itself includes proprietary DLLs that will need to be redistributed together with the application. The license appears to be proprietary, which means it will not be usable at least from GPL-licensed applications. MinGW-w64 cannot supply these DLLs, at l

Re: [Mingw-w64-public] gcc shows warning with

For reference, the warning is from https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=04784e33fabb45c4de7a901587f468d4bc169649 (new in binutils 2.40). Clang's inline assembly can parse the grotesque at&t syntax and generate Intel syntax [1]; I am a bit curious how this is done. Pretty s

Re: [Mingw-w64-public] [PATCH] gdtoa: Sync to match the latest version at netlib.org

Hi, it seems the mailing list software stripped your attached patch. Please try resending it with a .txt file extension. (I suspect that Gmail doesn't send the .patch files with the MIME type `text/plain`.) On 7/1/2023 11:10, Jameson Nash wrote: I noticed that gdtoa upstream appeared to have s

Re: [Mingw-w64-public] [patch ]add UTF-8 support for dirname and basename

Hi, if you attached a patch in your mail, it has been stripped by the mailing list software. Please try renaming it to `.txt` and resend. On 20/3/2023 16:55, 傅继晗 wrote: Hello maintainers: According to microsoft page:setlocale, _wsetlocale | Microsoft Learn

Re: [Mingw-w64-public] [patch ]add UTF-8 support for dirname and basename

Hi, Thanks for sending the patches. However my comment on these patches will be that, they only work when the process ANSI codepage (ACP) is UTF-8, which requires either embedding a manifest with activeCodePage set to UTF-8 or setting the system ACP to UTF-8. If the process is using CP936 (GB

Re: [Mingw-w64-public] [patch ]add UTF-8 support for dirname and basename

The thing is, the code point sequence you have here is not valid UTF-8 at all. If it is indeed doing the conversion from UTF-8 you will most likely get incorrect result or crashes. As you realized and reported in another reply that you were actually testing with msvcrt. It is likely that msvcr

Re: [Mingw-w64-public] [PATCH] rewrite the dirname.c and basename.c without wide character processing

Can we just avoid converting to wide char at all and operate only in MBCS? IsDBCSLeadByte should be enough to allow these functions to skip any false matches on the second byte of double-byte chars. And it does not matter that IsDBCSLeadByte doesn't work with UTF-8, because the UTF-8 encoding a

Re: [Mingw-w64-public] [PATCH] rewrite the dirname.c and basename.c without wide character processing

On 25/3/2023 17:28, LIU Hao wrote: 在 2023-03-25 12:35, Alvin Wong 写道: Can we just avoid converting to wide char at all and operate only in MBCS? IsDBCSLeadByte should be enough to allow these functions to skip any false matches on the second byte of double-byte chars. And it does not matter th

Re: [Mingw-w64-public] [PATCH] crt: Reimplement `dirname()` and `basename()`

Hi, Overall I think the implementation looks fine. The test cases are missing some of the more exotic DOS device paths[1], for example `\\.\Volume{b75e2c83----602f}\` but to be frank I don't know what should be the expected outputs for it. Should we simply declare that DOS

[Mingw-w64-public] [PATCH] headers: crt: Add declarations for _aligned_msize

Signed-off-by: Alvin Wong --- mingw-w64-headers/crt/crtdbg.h | 1 + mingw-w64-headers/crt/malloc.h | 1 + mingw-w64-headers/crt/stdlib.h | 1 + 3 files changed, 3 insertions(+) diff --git a/mingw-w64-headers/crt/crtdbg.h b/mingw-w64-headers/crt/crtdbg.h index c8b99c817..e24d5053b 100644 --- a/mi

[Mingw-w64-public] [PATCH] headers: crt: Add declarations for _aligned_msize

Signed-off-by: Alvin Wong --- > I think these declarations require checks for `__MSVCRT_VERSION__ >= 0x900`. They already have the checks. Resending with more context lines. mingw-w64-headers/crt/crtdbg.h | 1 + mingw-w64-headers/crt/malloc.h | 1 + mingw-w64-headers/crt/stdlib.h | 1 + 3 fi

Re: [Mingw-w64-public] [PATCH] crt: Remove conversion functions between UTF-{16, 32} characters from MSVCRT

Since there had been no other responses, I will add my opinion here: I am fine with removing these functions for msvcrt, only if mingw-w64 will never reimplement these functions in the future (i.e. will reject patches that add them). It seems very tricky to implement them correctly with msvcrt'

Re: [Mingw-w64-public] Linking with -lcomtl32 causes WinMain to never be called

This page contains an example of said manifest: https://learn.microsoft.com/en-us/windows/win32/controls/cookbook-overview On 8/5/2023 18:07, LIU Hao wrote: 在 2023/5/8 17:46, Maarten ten Velden 写道: The following should output atleast a (the LoadIconMetric call here is improper usage), but it

Re: [Mingw-w64-public] [PATCH] headers: remove conflicting declarations in qos2.h

Hi, I assume you attached a patch file with the file extension `.patch` but unfortunately it was stripped from the mailing list. (This happens a lot for patches sent from Gmail.) Can you resend it with the file extension changed to  `.txt`? Thanks. On 12/9/2023 22:48, Oleg Tolmatcev wrote: He

Re: [Mingw-w64-public] [PATCH] crt: Mark __guard_dispatch_icall_dummy as global

Seems reasonable to me, thanks for checking. On 31/10/2023 18:14, Martin Storsjö wrote: In LLVM LTO builds with cfguard enabled, the non-extern __guard_dispatch_icall_dummy can't pose as replacement for the undefined symbol reference to an extern __guard_dispatch_icall_dummy. Signed-off-by: Mar

Re: [Mingw-w64-public] Define __STDC_NO_THREADS__ if C11/C17 is not provided

Mind that Clang also does *not* currently define `__STDC_NO_THREADS__` for MinGW target. For MSVC target, this define was added in . Some of that discussion may also apply here. With glibc, apparently the compiler automatically includes `stdc-predef.h` which

[Mingw-w64-public] [PATCH] [RFC] crt: Add support for Control Flow Guard

(Note: the patches to add the Clang option hasn't landed yet, therefore this is still subject to change.) This adds support to enable building mingw-w64-crt and user code with Control Flow Gurad using Clang, with the option `--enable-cfguard`. In addition to adding the Clang 16 compiler option `

Re: [Mingw-w64-public] [PATCH] [RFC] crt: Add support for Control Flow Guard

Hi, On 7/9/2022 15:09, Martin Storsjö wrote: > On Sat, 3 Sep 2022, Alvin Wong via Mingw-w64-public wrote: > >> >> (Note: the patches to add the Clang option hasn't landed yet, therefore >> this is still subject to change.) > > Thanks a lot for your work on thi

Re: [Mingw-w64-public] [PATCH 2/3] crt: Provide the stack protector functions/variables in libmingwex too

Hi, On 14/9/2022 15:33, Martin Storsjö wrote: > +void __cdecl __attribute__((__noreturn__)) __stack_chk_fail(void) { > + char msg[] = "*** stack smashing detected ***: terminated\n"; > + write(STDERR_FILENO, msg, strlen(msg)); > + abort(); > +} I have a feeling that calling `abort()` may not b

Re: [Mingw-w64-public] [PATCH 2/3] crt: Provide the stack protector functions/variables in libmingwex too

Hi, On 15/9/2022 3:29, Martin Storsjö wrote: > On Thu, 15 Sep 2022, Alvin Wong wrote: > >> Hi, >> >> On 14/9/2022 15:33, Martin Storsjö wrote: >>> +void __cdecl __attribute__((__noreturn__)) __stack_chk_fail(void) { >>> +  char msg[] = "*** stack smashing detected ***: terminated\n"; >>> +  write(

[Mingw-w64-public] [PATCH v2] crt: Add support for Control Flow Guard

This adds support to enable building mingw-w64-crt and user code with Control Flow Guard using Clang, with the option `--enable-cfguard`. In addition to adding the Clang 16 compiler option `-mguard=cf` to CFLAGS, it also add two new objects to `libmingwex.a`: - `mingw_cfguard_support.c` contains t

[Mingw-w64-public] [PATCH v3] crt: Add support for Control Flow Guard

This adds support to enable building mingw-w64-crt and user code with Control Flow Guard using Clang, with the option `--enable-cfguard`. With this option enabled, the Clang 16 compiler option `-mguard=cf` will be added to CFLAGS when building mingw-w64-crt. Two new objects are also added to `libm