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

[Alvin Wong via Mingw-w64-public]

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 allows the libc to set this define, however there 
is no equivalent feature when it comes to MSVC and mingw-w64. It seems 
the only way to set this define for mingw-w64 is to hardcode it into the 
compiler.


On 9/11/2023 15:42, LIU Hao wrote:

在 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




___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

___
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 __guard_dispatch_icall_dummy as global

[Alvin Wong via Mingw-w64-public]

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: Martin Storsjö 
---
  mingw-w64-crt/cfguard/mingw_cfguard_support.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/mingw-w64-crt/cfguard/mingw_cfguard_support.c 
b/mingw-w64-crt/cfguard/mingw_cfguard_support.c
index cf4535afd..1e777ebfc 100644
--- a/mingw-w64-crt/cfguard/mingw_cfguard_support.c
+++ b/mingw-w64-crt/cfguard/mingw_cfguard_support.c
@@ -20,6 +20,7 @@ static void __guard_check_icall_dummy(void) {}
  // When CFGuard is not active, directly tail-call the target address, which
  // is passed via %rax.
  __asm__(
+".globl __guard_dispatch_icall_dummy\n"
  "__guard_dispatch_icall_dummy:\n"
  "jmp *%rax\n"
  );



___
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: remove conflicting declarations in qos2.h

[Alvin Wong via Mingw-w64-public]

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:

Hello,

This patch removes declarations that lead to compilation errors in Dolphin.

Best regards
Oleg

___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public



___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Alvin Wong via Mingw-w64-public]

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 doesn't even output a. Commenting out 
LoadIconMetric causes a to be output. The problem thus must be 
linking LoadIconMetric?


You need to load another version of COMCTL32.DLL, since the default 
one doesn't have that function. There is some information on this 
answer [1]. Unfortunately, GCC doesn't accept this #pragma thing and 
you will have to provide the manifest as an XML resource.



[1] 
https://social.msdn.microsoft.com/Forums/en-US/722193a4-7fba-4ed9-a41f-6629efdb2a78/loadiconmetric-corresponding-ordinal-number-380-could-not-be-located?forum=vcgeneral





___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public



___
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 conversion functions between UTF-{16, 32} characters from MSVCRT

[Alvin Wong via Mingw-w64-public]

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's definition of mbstate_t, anyway.


On 22/4/2023 20:46, LIU Hao wrote:

在 2023-03-30 16:38, LIU Hao 写道:
Ping on this patch. A blank line got deleted by accident. I can fix 
that locally.


Removal of stuff could be bad, but given that `mbstoc16()` has never 
been working, it might not be a big loss.




Ping again? It has been almost a month about this patch.




___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public



___
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: crt: Add declarations for _aligned_msize

[Alvin Wong via Mingw-w64-public]

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 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/mingw-w64-headers/crt/crtdbg.h
+++ b/mingw-w64-headers/crt/crtdbg.h
@@ -154,10 +154,11 @@ extern "C" {
 
 #if __MSVCRT_VERSION__ >= 0x900
 #define _recalloc_dbg(p,c,s,t,f,l) _recalloc(p,c,s)
 #define _aligned_recalloc_dbg(p,c,s,a,f,l) _aligned_realloc(p,c,s,a)
 #define _aligned_offset_recalloc_dbg(p,c,s,a,o,f,l) 
_aligned_offset_recalloc(p,c,s,a,o)
+#define _aligned_msize_dbg(p,a,o) _aligned_msize(p,a,o)
 #endif
 
 #define _malloca_dbg(s,t,f,l) _malloca(s)
 #define _freea_dbg(p,t) _freea(p)
 
diff --git a/mingw-w64-headers/crt/malloc.h b/mingw-w64-headers/crt/malloc.h
index c2003a19a..78599db94 100644
--- a/mingw-w64-headers/crt/malloc.h
+++ b/mingw-w64-headers/crt/malloc.h
@@ -67,10 +67,11 @@ extern "C" {
   _CRTIMP void *__cdecl _aligned_offset_realloc(void *_Memory,size_t 
_Size,size_t _Alignment,size_t _Offset);
 # if __MSVCRT_VERSION__ >= 0x900
   _CRTIMP void *__cdecl _recalloc(void *_Memory,size_t _Count,size_t _Size);
   _CRTIMP void *__cdecl _aligned_recalloc(void *_Memory,size_t _Count,size_t 
_Size,size_t _Alignment);
   _CRTIMP void *__cdecl _aligned_offset_recalloc(void *_Memory,size_t 
_Count,size_t _Size,size_t _Alignment,size_t _Offset);
+  _CRTIMP size_t __cdecl _aligned_msize(void *_Memory,size_t _Alignment,size_t 
_Offset);
 # endif
 #endif
 
 /* Users should really use MS provided versions */
 void * __mingw_aligned_malloc (size_t _Size, size_t _Alignment);
diff --git a/mingw-w64-headers/crt/stdlib.h b/mingw-w64-headers/crt/stdlib.h
index 63aea7bfe..8e2649491 100644
--- a/mingw-w64-headers/crt/stdlib.h
+++ b/mingw-w64-headers/crt/stdlib.h
@@ -544,10 +544,11 @@ float __cdecl __MINGW_NOTHROW strtof(const char * 
__restrict__ _Str,char ** __re
   _CRTIMP void *__cdecl _aligned_offset_realloc(void *_Memory,size_t 
_Size,size_t _Alignment,size_t _Offset);
 # if __MSVCRT_VERSION__ >= 0x900
   _CRTIMP void *__cdecl _recalloc(void *_Memory,size_t _Count,size_t _Size);
   _CRTIMP void *__cdecl _aligned_recalloc(void *_Memory,size_t _Count,size_t 
_Size,size_t _Alignment);
   _CRTIMP void *__cdecl _aligned_offset_recalloc(void *_Memory,size_t 
_Count,size_t _Size,size_t _Alignment,size_t _Offset);
+  _CRTIMP size_t __cdecl _aligned_msize(void *_Memory,size_t _Alignment,size_t 
_Offset);
 # endif
 #endif
 
 #ifndef _WSTDLIB_DEFINED
 #define _WSTDLIB_DEFINED
-- 
2.40.0



___
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: crt: Add declarations for _aligned_msize

[Alvin Wong via Mingw-w64-public]

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/mingw-w64-headers/crt/crtdbg.h
+++ b/mingw-w64-headers/crt/crtdbg.h
@@ -156,6 +156,7 @@ extern "C" {
 #define _recalloc_dbg(p,c,s,t,f,l) _recalloc(p,c,s)
 #define _aligned_recalloc_dbg(p,c,s,a,f,l) _aligned_realloc(p,c,s,a)
 #define _aligned_offset_recalloc_dbg(p,c,s,a,o,f,l) 
_aligned_offset_recalloc(p,c,s,a,o)
+#define _aligned_msize_dbg(p,a,o) _aligned_msize(p,a,o)
 #endif
 
 #define _malloca_dbg(s,t,f,l) _malloca(s)
diff --git a/mingw-w64-headers/crt/malloc.h b/mingw-w64-headers/crt/malloc.h
index c2003a19a..78599db94 100644
--- a/mingw-w64-headers/crt/malloc.h
+++ b/mingw-w64-headers/crt/malloc.h
@@ -69,6 +69,7 @@ extern "C" {
   _CRTIMP void *__cdecl _recalloc(void *_Memory,size_t _Count,size_t _Size);
   _CRTIMP void *__cdecl _aligned_recalloc(void *_Memory,size_t _Count,size_t 
_Size,size_t _Alignment);
   _CRTIMP void *__cdecl _aligned_offset_recalloc(void *_Memory,size_t 
_Count,size_t _Size,size_t _Alignment,size_t _Offset);
+  _CRTIMP size_t __cdecl _aligned_msize(void *_Memory,size_t _Alignment,size_t 
_Offset);
 # endif
 #endif
 
diff --git a/mingw-w64-headers/crt/stdlib.h b/mingw-w64-headers/crt/stdlib.h
index 63aea7bfe..8e2649491 100644
--- a/mingw-w64-headers/crt/stdlib.h
+++ b/mingw-w64-headers/crt/stdlib.h
@@ -546,6 +546,7 @@ float __cdecl __MINGW_NOTHROW strtof(const char * 
__restrict__ _Str,char ** __re
   _CRTIMP void *__cdecl _recalloc(void *_Memory,size_t _Count,size_t _Size);
   _CRTIMP void *__cdecl _aligned_recalloc(void *_Memory,size_t _Count,size_t 
_Size,size_t _Alignment);
   _CRTIMP void *__cdecl _aligned_offset_recalloc(void *_Memory,size_t 
_Count,size_t _Size,size_t _Alignment,size_t _Offset);
+  _CRTIMP size_t __cdecl _aligned_msize(void *_Memory,size_t _Alignment,size_t 
_Offset);
 # endif
 #endif
 
-- 
2.40.0



___
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: Reimplement `dirname()` and `basename()`

[Alvin Wong via Mingw-w64-public]

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 device paths may not work as expected?


[1]: 
https://learn.microsoft.com/en-us/dotnet/standard/io/file-path-formats#dos-device-paths


Manual fuzzing with asan and ubsan revealed an issue: The line 
`info.prefix_end[1] = 0;` (line 213) can result in a buffer overrun. 
This happens with inputs in the form of an UNC host only, e.g. `\\host`, 
which is also missing from the test cases.


I would think the fix is as simple as changing line 211 to 
`if(info.prefix_end < info.path_end - 1) {`, but this revealed another 
issue because `info.path_end` contained an uninitialized value -- an 
early return in `do_get_path_info` (line 127) missed setting 
`info->path_end = pos;`. After applying these fixes there seems to be no 
other sanitizer issues. I have attached my test which I built with 
`clang -fsanitize=address,undefined`.


Cheers,
Alvin


On 26/3/2023 17:09, LIU Hao wrote:
As discussed on IRC just now, paths are not affected by the global 
locale. According to Microsoft documentation about `fopen()` [1], 
paths are interpreted with `CP_ACP` if `AreFileApisANSI()` returns 
true, and `CP_OEMCP` otherwise. We had better follow that convention.



[1] 
https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/fopen-wfopen?view=msvc-170




___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public#define TEST_CODEPAGE 950
// #define TEST_CODEPAGE CP_UTF8

#define _CRT_RAND_S

// -

/**
 * 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 WIN32_LEAN_AND_MEAN
#define WIN32_LEAN_AND_MEAN
#endif
#include 
#include 
#include 

/* A 'directory separator' is a byte that equals 0x2F ('solidus' or more
 * commonly 'forward slash') or 0x5C ('reverse solidus' or more commonly
 * 'backward slash'). The byte 0x5C may look different from a backward slash
 * in some locales; for example, it looks the same as a Yen sign in Japanese
 * locales and a Won sign in Korean locales. Despite its appearance, it still
 * functions as a directory separator.
 *
 * A 'path' comprises an optional DOS drive letter with a colon, and then an
 * arbitrary number of possibily empty components, separated by non-empty
 * sequences of directory separators (in other words, consecutive directory
 * separators are treated as a single one). A path that comprises an empty
 * component denotes the current working directory.
 *
 * An 'absolute path' comprises at least two components, the first of which
 * is empty.
 *
 * A 'relative path' is a path that is not an absolute path. In other words,
 * it either comprises an empty component, or begins with a non-empty
 * component.
 *
 * POSIX doesn't have a concept about DOS drives. A path that does not have a
 * drive letter starts from the same drive as the current working directory.
 *
 * For example:
 * (Examples without drive letters match POSIX.)
 *
 *   Argument dirname() returnsbasename() returns
 *    ---
 *   `` or NULL   `.`  `.`
 *   `usr``.`  `usr`
 *   `usr\`   `.`  `usr`
 *   `\`  `\`  `\`
 *   `\usr`   `\`  `usr`
 *   `\usr\lib`   `\usr`   `lib`
 *   `\home\\dwc\\test`   `\home\\dwc` `test`
 *   `\\host\usr` `\\host\.`   `usr`
 *   `\\host\usr\lib` `\\host\usr` `lib`
 *   `\\host\\usr``\\host\\`   `usr`
 *   `\\host\\usr\lib``\\host\\usr``lib`
 *   `C:` `C:.``.`
 *   `C:usr`  `C:.``usr`
 *   `C:usr\` `C:.``usr`
 *   `C:\``C:\``\`
 *   `C:\\`   `C:\``\`
 *   `C:\\\`  `C:\``\`
 *   `C:\usr` `C:\``usr`
 *   `C:\usr\lib` `C:\usr` `lib`
 *   `C:\\usr\\lib\\` `C:\\usr``lib`
 *   `C:\home\\dwc\\test` `C:\home\\dwc`   `test`
 */

struct path_info
  {
/* This points to end of the UNC prefix and drive letter, if any.  */
char* prefix_end;

/* These point to the directory 

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

[Alvin Wong via Mingw-w64-public]

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 that IsDBCSLeadByte doesn't work with UTF-8, 
because the UTF-8 encoding already ensures that there will be no 
false matches with 7-bit ASCII chars (all bytes forming multi-byte 
chars have the MSB set, unlike some DBCS).


While this argument is almost correct on its own (except that 
`IsDBCSLeadByteEx()` is preferred to `IsDBCSLeadByte()`), we should 
not declare these functions as working with UTF-8. As explained in a 
previous message, the Yen symbol (`¥`, two bytes in UTF-8: C2 A5) is a 
path separator in Japanese locales, and the Won symbol (`₩`, three 
bytes in UTF-8: E2 82 A9) is also a path separator in Korean locales;


This claim needs to be verified. The native path separator on Windows 
should be only U+005C (with APIs also accepting U+002F). While both 
U+005C and U+00A5 translates to 0x5C in CP932, Windows uses Unicode to 
handle files and NTFS uses Unicode file names. If you give Windows the 
path `L"C:\134new\245folder"`, I can't really imagine it referring to 
`C:\new\folder` rather than `C:\new¥folder` when system code page is in 
Japanese. Of course, if you first translate the path to CP932, or if you 
are using a program that does not use the Unicode Windows APIs, then you 
will not be able to refer to `new¥folder`.


I think the following things need to be checked:

1.  From Windows Explorer, can you create a file or folder containing
   U+00A5 in its name on Japanese Windows? (Don't try from cmd.exe.)
2. If you create a file or folder containing U+00A5 on an NTFS volume
   from another non-Japanese system, can you access it from Windows
   Explorer on Japanese Windows?
3. Create the path `C:\new\folder` and try to access it using the
   Unicode Windows API with the path `L"C:\134new\245folder"`.
4. Create the path `C:\new¥folder` (with U+00A5) and try the same.
5. Check the above two points, but with embedded manifest setting the
   active code page to UTF-8, and using the "-A" APIs with a UTF-8
   string instead.
6. Check whether MultiByteToWideChar converts 0x5C from CP932 to U+005C
   or U+00A5.

Remember that U+005C and U+00A5 can look exactly the same in the 
Japanese font on Windows, so you should verify you have the correct code 
point when testing.


those are not something we can handle, because we can't know the 
encoding of the argument string.
We can check the value of `GetACP()`, although I am not convinced we 
need to.

___
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] rewrite the dirname.c and basename.c without wide character processing

[Alvin Wong via Mingw-w64-public]

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 already ensures that there will be no false matches with 
7-bit ASCII chars (all bytes forming multi-byte chars have the MSB set, 
unlike some DBCS).



On 23/3/2023 13:29, LIU Hao wrote:

在 2023-03-22 13:40, 傅继晗 写道:

Hello:
There is no need to convert multi-byte characters to wide-byte 
characters and then convert from wide-byte to multi-byte, just deal 
with multi-byte directly as __xpg_basename in gnu as this：
glibc/xpg_basename.c at master · lattera/glibc (github.com) 

Converting multi-byte characters to wide-byte characters can lead to 
garbled code problems if the incoming filename encoding does not 
match the system default encoding returned by GetACP().And 
environment variables do not work there.


I was also thinking about reimplementation of these functions, but 
there are things that we must take care of:


1. The conversion from multibyte character strings (MBCS) to wide 
character
   strings (WCS) is necessary, because non-leading bytes in some MBCS 
encodings

   may match the black slash `\` (U+005C).

2. Not only forward and backward slashes are path separators. The 
conventional
   Shift JIS encoding has the Yen symbol `¥` (U+00A5) take the place 
of the
   ASCII backslash, and a Yen symbol is displayed for the byte 0x5C if 
a Shift
   JIS locale is activated. This means that `mbstowc()` will convert 
the string
   "a¥b" (hex: 61 5C 62) to L"a¥b" (hex: 0061 00A5 0062) and we have 
to also

   accept `¥` as a path separator in Japanese locales.

3. Something similar to 2 happens about the Won symbol `₩` (U+20A9) in 
Korean

   locales, so we have to accept it, too.

4. Don't ever try to modify the global locale, due to thread safety.


OK, it has been too much. How do we implement this correctly? First we 
need to make an assumption about the input, for example, let's assume 
it is a path in Shift JIS encoding.


1. Don't check wide characters for path separators! As explained 
above, not only
   slashes are path separators. Japanese and Korean are what I happen 
to know,
   but there could be a couple more. We notice that the byte 5C is 
always a path
   separator, no matter what it may map to, `\`, `¥` or `₩`. Hence, 
only the
   original MBCS should be scanned for path separators, which are `/` 
(U+002F)

   and `\` (U+005C), but nothing else.

2. It's necessary to convert it to a WCS first. Ideally the caller 
should have
   set the global locale... but are they aware of it? Maybe this 
should be done

   via `MultiByteToWideChar()`, like other functions.

3. So what is the conversion for? We can't make use of the output of such
   conversion, but it gives information about how many bytes that a 
character
   takes in the original MBCS, so we can know how many bytes to move 
forward (a
   multiple-byte character is never a path separator), and will not a 
mistake

   non-leading byte as a path separator.





___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public



___
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 UTF-8 support for dirname and basename

[Alvin Wong via Mingw-w64-public]

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 msvcrt just ignored the 
unsupported locale and was doing something unspecified.


On 20/3/2023 19:07, 傅继晗 wrote:
However,I use GBK  as default code page in my windows , and I try to 
test it with GBK encoding content .But this trick seems still 
work.Here is the test case.


#include 
extern char * __cdecl basename (char *path);
void xprint(const char *s)
{
    while (*s)
        printf("\\x%02x", (int)(unsigned char)(*s++));
}

int main(int argc, char **argv)
{
    char input[] 
={0x2f,0x73,0x64,0x63,0x61,0x72,0x64,0x2f,0xcc,0xec,0xcc,0xec,0xcf,0xf2,0xc9,0xcf,0x00}; 
// it is gbk encoding of "/sdcard/天天向上"

    char *output;
    printf("basename(\"");
    xprint(input);
    printf("\") = \"");
    output = basename(input);
    xprint(output);
    printf("\"\n");
    return 0;
}



Alvin Wong  于2023年3月20日周一 18:52写道：

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 (GBK) for example, it
will still be broken similar to before.

Just my two cents: I would prefer to remove any code that changes
the locale then attempt to restore it (which is not thread-safe),
then replace `mbstowcs` and `wcstombs` with direct usage of
`MultiByteToWideChar` and `WideCharToMultiByte`, which can convert
from/to CP_ACP directly.

Best Regards,
Alvin

On 20/3/2023 18:36, 傅继晗 wrote:

ok，it has txt extension now

Alvin Wong  于2023年3月20日周一 18:10写道：

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
>


>
> *Starting in Windows 10 version 1803 (10.0.17134.0), the
Universal C
> Runtime supports using a UTF-8 code page. The change means
that char
> strings passed to C runtime functions can expect strings in
the UTF-8
> encoding.*
>
> But the libmingwex.a in toolchain of Mingw-w64-public 
doesn't support
> non-ascii file name,and cause some bugs in project,see :
> MinGW-w64 - for 32 and 64 bit Windows / Bugs / #227
basename() truncates
> filenames with variable-width encoding (sourceforge.net
)
> 
> and AOSP adb pull push error
> Google Issue Tracker

>
> so,the patches for dirname.c and basename.c is needed to
support utf-8
> encoding.
>
> Greetings
>
> fjh1997
>
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


___
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 UTF-8 support for dirname and basename

[Alvin Wong via Mingw-w64-public]

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 
(GBK) for example, it will still be broken similar to before.


Just my two cents: I would prefer to remove any code that changes the 
locale then attempt to restore it (which is not thread-safe), then 
replace `mbstowcs` and `wcstombs` with direct usage of 
`MultiByteToWideChar` and `WideCharToMultiByte`, which can convert 
from/to CP_ACP directly.


Best Regards,
Alvin

On 20/3/2023 18:36, 傅继晗 wrote:

ok，it has txt extension now

Alvin Wong  于2023年3月20日周一 18:10写道：

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
>


>
> *Starting in Windows 10 version 1803 (10.0.17134.0), the Universal C
> Runtime supports using a UTF-8 code page. The change means that char
> strings passed to C runtime functions can expect strings in the
UTF-8
> encoding.*
>
> But the libmingwex.a in toolchain of Mingw-w64-public doesn't
support
> non-ascii file name,and cause some bugs in  project,see :
> MinGW-w64 - for 32 and 64 bit Windows / Bugs / #227 basename()
truncates
> filenames with variable-width encoding (sourceforge.net
)
> 
> and AOSP adb pull push error
> Google Issue Tracker

>
> so,the patches for dirname.c and basename.c is needed to support
utf-8
> encoding.
>
> Greetings
>
> fjh1997
>
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


___
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 UTF-8 support for dirname and basename

[Alvin Wong via Mingw-w64-public]

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


*Starting in Windows 10 version 1803 (10.0.17134.0), the Universal C
Runtime supports using a UTF-8 code page. The change means that char
strings passed to C runtime functions can expect strings in the UTF-8
encoding.*

But the libmingwex.a in toolchain of Mingw-w64-public  doesn't support
non-ascii file name,and cause some bugs in  project,see :
MinGW-w64 - for 32 and 64 bit Windows / Bugs / #227 basename() truncates
filenames with variable-width encoding (sourceforge.net)

and AOSP adb pull push error
Google Issue Tracker 

so,the patches for dirname.c and basename.c is needed to support utf-8
encoding.

Greetings

fjh1997

___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public



___
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] gdtoa: Sync to match the latest version at netlib.org

[Alvin Wong via Mingw-w64-public]

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 some changes that were not
reflected here, so I tried to copy them into mingw-w64 here. I had to
partly guess at what the diff was between the old and current versions
because upstream does not seem to provide version control, so this is a bit
hard to illustrate. For future reference, this is the content from today:
https://github.com/vtjnash/gdtoa/commit/a37a5e1354210f135003cc734cb097eee48e58b5,
which is also included as a tgz in the commit here for future reference. I
did not import any of the new features (new files) since those are not
specified as part of C9x or POSIX, so they did not seem necessary.

___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public



___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Alvin Wong via Mingw-w64-public]

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 syntax and 
generate Intel syntax [1]; I am a bit curious how this is done.
Pretty sure Compiler Explorer is just using the `-masm=intel` command 
line flag, which both Clang and GCC supports.



On 24/2/2023 0:49, LIU Hao wrote:

在 2023-02-21 00:09, Biswapriyo Nath 写道:

  __INTRINSICS_USEINLINE
-__buildmov(__movsd, unsigned __LONG32, "d")
+__buildmov(__movsd, unsigned __LONG32, "l")
  #endif
  #define __INTRINSIC_DEFINED___movsd
  #endif /* __INTRINSIC_PROLOG */

I am not sure if this is valid fix. Feel free to apply the diff as
maintainers like. A little explanation would be helpful also.



This looks correct.

Clang's inline assembly can parse the grotesque at syntax and 
generate Intel syntax [1]; I am a bit curious how this is done. Clang 
seems to accept both.



[1] https://gcc.godbolt.org/z/6z11qTYa7






___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public



___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Alvin Wong via Mingw-w64-public]

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 least not without a clean-room reimplementation, so it doesn't 
seem to make sense for MinGW-w64 to add the include headers and the 
import lib for this API for now.


If the license is not a problem for you, you can probably download the 
NuGet package and extract the files from it. The headers may not work 
out of the box but I guess it shouldn't be too difficult to adapt them 
to work with MinGW-w64.


Note: The above reflects my personal opinion only.

Best Regards,
Alvin

On 17/1/2023 20:40, Rishabh Shukla wrote:

Hi Team MinGW,

Microsoft has introduced new set of APIs to support DirectStorage, that can be 
included through nuget/vcpkg; it includes,
lib and dll-
 dstorage.lib
 dstorage.dll
 dstoragecore.dll
headers-
 dstorage.h
 dstorageerr.h

Please check the below mentioned link for more information,
https://devblogs.microsoft.com/directx/directstorage-api-downloads/

Is it possible for you guys to add support for the above mentioned headers and 
libraries in MinGW packages?

Please let me know your thoughts on this.


Thanks you for all your work and support.


Regards,
Rishabh


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public



___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Alvin Wong via Mingw-w64-public]

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-headers/include/shcore.h
new file mode 100644
index 0..b51d5c488
--- /dev/null
+++ b/mingw-w64-headers/include/shcore.h
@@ -0,0 +1,33 @@
+/**
+ * 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 _SHCORE_H_
+#define _SHCORE_H_
+
+#include 
+
+#if NTDDI_VERSION >= NTDDI_WIN8
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+typedef enum {
+BSOS_DEFAULT = 0,
+BSOS_PREFERDESTINATIONSTREAM
+} BSOS_OPTIONS;
+
+STDAPI CreateRandomAccessStreamOnFile(PCWSTR filePath, DWORD accessMode, 
REFIID riid, void **ppv);
+STDAPI CreateRandomAccessStreamOverStream(IStream *stream, BSOS_OPTIONS 
options, REFIID riid, void **ppv);
+STDAPI CreateStreamOverRandomAccessStream(IUnknown *randomAccessStream, REFIID 
riid, void **ppv);
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* NTDDI_VERSION >= NTDDI_WIN8 */
+
+#endif
-- 
2.39.0



___
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 shcore.h

[Alvin Wong via Mingw-w64-public]

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-headers/include/shcore.h | 33 ++
  1 file changed, 33 insertions(+)
  create mode 100644 mingw-w64-headers/include/shcore.h




+STDAPI CreateRandomAccessStreamOnFile(PCWSTR filePath, DWORD 
accessMode, REFIID riid, void **ppv);
+STDAPI CreateRandomAccessStreamOverStream(IStream *stream, 
BSOS_OPTIONS options, REFIID riid, void **ppv);
+STDAPI CreateStreamOverRandomAccessStream(IUnknown 
*randomAccessStream, REFIID riid, void **ppv);

+


Please include the dllimport attributes

Should I use `DECLSPEC_IMPORT HRESULT WINAPI` instead of `STDAPI` then?

and provide the library def file from gendef.

That `shcore.def` already exists in mingw-w64.


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Alvin Wong via Mingw-w64-public]

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 does not actually have an IDL file for robuffer.h, and
its robuffer.h only defines the interface in C++. It also doesn't
declare an IID for this interface (only the UUID for __uuidof is
provided.)

The header generated from this IID should provide functionally identical
definitions as the one from Windows SDK. Additionally, it also provide
extra declarations including the IID and the C definition of the vtable
of IBufferByteAccess, which in theory would allow users to implement
this interface. But any user code that does this will be incompatible
with MSVC unless they provide compatible definitions themselves.

 mingw-w64-headers/Makefile.am  |  1 +
 mingw-w64-headers/include/robuffer.idl | 28 ++
 2 files changed, 29 insertions(+)
 create mode 100644 mingw-w64-headers/include/robuffer.idl

diff --git a/mingw-w64-headers/Makefile.am b/mingw-w64-headers/Makefile.am
index ee3601209..dcdee4c03 100644
--- a/mingw-w64-headers/Makefile.am
+++ b/mingw-w64-headers/Makefile.am
@@ -252,6 +252,7 @@ IDL_SRCS = \
   include/qedit.idl \
   include/qnetwork.idl \
   include/relogger.idl \
+  include/robuffer.idl \
   include/rtworkq.idl \
   include/vmr9.idl \
   include/wincodec.idl \
diff --git a/mingw-w64-headers/include/robuffer.idl 
b/mingw-w64-headers/include/robuffer.idl
new file mode 100644
index 0..cc9225627
--- /dev/null
+++ b/mingw-w64-headers/include/robuffer.idl
@@ -0,0 +1,28 @@
+/**
+ * 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.
+ */
+
+#ifdef __WIDL__
+#pragma winrt
+#endif
+
+import "objidl.idl";
+
+cpp_quote("#if NTDDI_VERSION >= NTDDI_WIN8")
+
+namespace Windows.Storage.Streams {
+
+[
+uuid(905a0fef-bc53-11df-8c49-001e4fc686da),
+]
+interface IBufferByteAccess : IUnknown
+{
+HRESULT Buffer([out, retval] byte **value);
+}
+
+}
+
+cpp_quote("STDAPI RoGetBufferMarshaler(IMarshal **bufferMarshaler);")
+cpp_quote("#endif")
-- 
2.39.0



___
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: Add shcore.h

[Alvin Wong via Mingw-w64-public]

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 mingw-w64-headers/include/shcore.h

diff --git a/mingw-w64-headers/include/shcore.h 
b/mingw-w64-headers/include/shcore.h
new file mode 100644
index 0..bea583d5b
--- /dev/null
+++ b/mingw-w64-headers/include/shcore.h
@@ -0,0 +1,33 @@
+/**
+ * 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 _SHCORE_H_
+#define _SHCORE_H_
+
+#include 
+
+#if NTDDI_VERSION >= NTDDI_WIN8
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+typedef enum {
+BSOS_DEFAULT = 0,
+BSOS_PREFERDESTINATIONSTREAM,
+} BSOS_OPTIONS;
+
+STDAPI CreateRandomAccessStreamOnFile(PCWSTR filePath, DWORD accessMode, 
REFIID riid, void **ppv);
+STDAPI CreateRandomAccessStreamOverStream(IStream *stream, BSOS_OPTIONS 
options, REFIID riid, void **ppv);
+STDAPI CreateStreamOverRandomAccessStream(IUnknown *randomAccessStream, REFIID 
riid, void **ppv);
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* NTDDI_VERSION >= NTDDI_WIN8 */
+
+#endif
-- 
2.39.0



___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Alvin Wong via Mingw-w64-public]

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 you don't need to use any COM interfaces. 
`#include ` will bring back the `interface` macro.




___
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: Add systemmediatransportcontrolsinterop.idl

[Alvin Wong via Mingw-w64-public]

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/mingw-w64-headers/Makefile.am b/mingw-w64-headers/Makefile.am
index 6e026f19a..ee3601209 100644
--- a/mingw-w64-headers/Makefile.am
+++ b/mingw-w64-headers/Makefile.am
@@ -214,6 +214,7 @@ IDL_SRCS = \
   include/spellcheck.idl \
   include/strmif.idl \
   include/structuredquerycondition.idl \
+  include/systemmediatransportcontrolsinterop.idl \
   include/taskschd.idl \
   include/textstor.idl \
   include/thumbcache.idl \
diff --git a/mingw-w64-headers/include/systemmediatransportcontrolsinterop.idl 
b/mingw-w64-headers/include/systemmediatransportcontrolsinterop.idl
new file mode 100644
index 0..265ae0536
--- /dev/null
+++ b/mingw-w64-headers/include/systemmediatransportcontrolsinterop.idl
@@ -0,0 +1,15 @@
+/**
+ * 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.
+ */
+
+import "inspectable.idl";
+
+[
+uuid(ddb0472d-c911-4a1f-86d9-dc3d71a95f5a),
+]
+interface ISystemMediaTransportControlsInterop : IInspectable
+{
+HRESULT GetForWindow([in] HWND appWindow, [in] REFIID riid, [out, retval, 
iid_is(riid)] void **mediaTransportControl);
+}
-- 
2.38.1



___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Alvin Wong via Mingw-w64-public]

Do you mean building a mingw-w64 cross compilation toolchain on riscv 
for cross-compiling on a riscv Linux host, or building a toolchain 
targeting Windows on riscv?


The former (cross toolchain on riscv host) should not be much different 
than on other architectures. If you do encounter issues when building 
such toolchains (like issues building host tool) you are welcomed to ask 
for help, or submit patches if the issue is from inside mingw-w64.


The latter is something that does not currently exist at all, and has no 
reason to exist. Until Microsoft actually publicly releases a build 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 Wine, so
any changes should be submitted to the other upstream:
https://gitlab.winehq.org/wine/wine/-/blob/master/include/basetsd.h

Thanks for correcting me about this. I will update the changes to wine.

btw, about mingw-w64 to support riscv64, could you give some advices?
maybe I just to try build it on riscv64 machines. But I think your help is very
valuable.

thank you.

BR,
Bo

Cheers,
Alvin

On 13/12/2022 16:08, Bo YU wrote:

Hi,

I asked about the possibility on IRC about a few months ago, but the
answer is not positive in my view. Recently I got some reports that
some packages from others distro will depend on mingw-w64 on riscv64
arch. So I think it is better to support riscv64 from upstream.

The patch I have submitted to Debian[0] is very simple but it can be
built. If there is more to do please let me know, thanks.

[0]: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1014392;filename=add-support-riscv64.patch;msg=15

BR,
Bo


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public



___
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 riscv64?

[Alvin Wong via Mingw-w64-public]

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 about a few months ago, but the
answer is not positive in my view. Recently I got some reports that
some packages from others distro will depend on mingw-w64 on riscv64
arch. So I think it is better to support riscv64 from upstream.

The patch I have submitted to Debian[0] is very simple but it can be
built. If there is more to do please let me know, thanks.

[0]: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1014392;filename=add-support-riscv64.patch;msg=15

BR,
Bo


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public



___
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 v3] headers: Implement quaternion functions in windowsnumerics.h

[Alvin Wong via Mingw-w64-public]

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: Left out the float4x4 decompose function from this patch.
---
  .../include/windowsnumerics.impl.h| 160 +++---
  .../testcases/test_windowsnumerics.cpp| 104 +++-
  2 files changed, 244 insertions(+), 20 deletions(-)



___
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: Implement quaternion functions in windowsnumerics.h

[Alvin Wong via Mingw-w64-public]

On 22/11/2022 20:07, Martin Storsjö wrote:

+  inline bool decompose(const float4x4 , 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;
+float3 scale = float3(
+  length(float3(val.m11, val.m12, val.m13)),
+  length(float3(val.m21, val.m22, val.m23)),
+  length(float3(val.m31, val.m32, val.m33))
+);
+if (out_scale)
+  *out_scale = scale;
+val = make_float4x4_scale(float3(1.0f/scale.x, 1.0f/scale.y, 
1.0f/scale.z)) * val;
+if (out_rot)
+  *out_rot = make_quaternion_from_rotation_matrix(val);
+return true;
+  }


I feel that there should be some conditions that cause this function to 
return false, if the input is not a scale/rotate/translate matrix...




___
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/shlobj.h: Add missing KNOWN_FOLDER_FLAG constants

[Alvin Wong via Mingw-w64-public]

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

diff --git a/mingw-w64-headers/include/shlobj.h 
b/mingw-w64-headers/include/shlobj.h
index be087c4fe..c775f50b5 100644
--- a/mingw-w64-headers/include/shlobj.h
+++ b/mingw-w64-headers/include/shlobj.h
@@ -734,6 +734,17 @@ extern "C" {
 #if NTDDI_VERSION >= 0x0600
   typedef enum {
 KF_FLAG_DEFAULT = 0x,
+#if NTDDI_VERSION >= NTDDI_WIN10_RS3
+KF_FLAG_FORCE_APP_DATA_REDIRECTION = 0x0008,
+#endif
+#if NTDDI_VERSION >= NTDDI_WIN10_RS2
+KF_FLAG_RETURN_FILTER_REDIRECTION_TARGET = 0x0004,
+KF_FLAG_FORCE_PACKAGE_REDIRECTION = 0x0002,
+KF_FLAG_NO_PACKAGE_REDIRECTION = 0x0001,
+#endif
+#if NTDDI_VERSION >= NTDDI_WIN8
+KF_FLAG_FORCE_APPCONTAINER_REDIRECTION = 0x0002,
+#endif
 #if NTDDI_VERSION >= 0x0601
 KF_FLAG_NO_APPCONTAINER_REDIRECTION = 0x0001,
 #endif
-- 
2.38.1



___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Alvin Wong via Mingw-w64-public]

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

Signed-off-by: Alvin Wong 
---
 mingw-w64-headers/include/windowsnumerics.h   |   30 +
 .../include/windowsnumerics.impl.h| 1064 +
 .../testcases/test_windowsnumerics.cpp|  955 +++
 3 files changed, 2049 insertions(+)
 create mode 100644 mingw-w64-headers/include/windowsnumerics.h
 create mode 100644 mingw-w64-headers/include/windowsnumerics.impl.h
 create mode 100644 mingw-w64-headers/testcases/test_windowsnumerics.cpp

diff --git a/mingw-w64-headers/include/windowsnumerics.h 
b/mingw-w64-headers/include/windowsnumerics.h
new file mode 100644
index 0..e97086538
--- /dev/null
+++ b/mingw-w64-headers/include/windowsnumerics.h
@@ -0,0 +1,30 @@
+/**
+ * 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 _WINDOWSNUMERICS_
+#define _WINDOWSNUMERICS_
+
+#ifndef __cplusplus
+#error windowsnumerics.h requires C++
+#endif /* __cplusplus */
+
+#define _WINDOWS_NUMERICS_NAMESPACE_ Windows::Foundation::Numerics
+
+#define _WINDOWS_NUMERICS_BEGIN_NAMESPACE_ \
+  namespace Windows { \
+namespace Foundation { \
+  namespace Numerics
+
+#define _WINDOWS_NUMERICS_END_NAMESPACE_ \
+} \
+  }
+
+#include "windowsnumerics.impl.h"
+
+#undef _WINDOWS_NUMERICS_NAMESPACE_
+#undef _WINDOWS_NUMERICS_BEGIN_NAMESPACE_
+#undef _WINDOWS_NUMERICS_END_NAMESPACE_
+
+#endif /* _WINDOWSNUMERICS_ */
diff --git a/mingw-w64-headers/include/windowsnumerics.impl.h 
b/mingw-w64-headers/include/windowsnumerics.impl.h
new file mode 100644
index 0..7785b1eba
--- /dev/null
+++ b/mingw-w64-headers/include/windowsnumerics.impl.h
@@ -0,0 +1,1064 @@
+/**
+ * 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.
+ */
+
+/**
+ * Normal users should include `windowsnumerics.h` instead of this header.
+ * However, the cppwinrt headers set `_WINDOWS_NUMERICS_NAMESPACE_`,
+ * `_WINDOWS_NUMERICS_BEGIN_NAMESPACE_` and `_WINDOWS_NUMERICS_END_NAMESPACE_`
+ * to custom values and include `windowsnumerics.impl.h`. Therefore this shall
+ * be considered a public header, and these macros are public API.
+*/
+
+
+#ifdef min
+#  pragma push_macro("min")
+#  undef min
+#  define _WINDOWS_NUMERICS_IMPL_PUSHED_MIN_
+#endif
+
+#ifdef max
+#  pragma push_macro("max")
+#  undef max
+#  define _WINDOWS_NUMERICS_IMPL_PUSHED_MAX_
+#endif
+
+#include 
+#include 
+
+#include "directxmath.h"
+
+
+// === Internal macros ===
+#define _WINDOWS_NUMERICS_IMPL_ASSIGN_OP(_ty1, _op, _ty2) \
+  inline _ty1  _op ## =(_ty1 , _ty2 val2) { \
+val1 = operator _op (val1, val2); \
+return val1; \
+  }
+
+
+// === Internal functions ===
+_WINDOWS_NUMERICS_BEGIN_NAMESPACE_ {
+  namespace _impl {
+
+#if 0 && defined(__cpp_lib_clamp)
+using std::clamp;
+#else
+constexpr const float (const float , const float , const 
float ) {
+  return val < min ? min : (val > max ? max : val);
+}
+#endif
+
+#if 0 && defined(__cpp_lib_interpolate)
+using std::lerp;
+#else
+constexpr float lerp(float val1, float val2, float amount) {
+  // Don't do (val2 - val1) * amount + val1 as it has worse precision.
+  return val2 * amount + val1 * (1.0f - amount);
+}
+#endif
+
+  }
+} _WINDOWS_NUMERICS_END_NAMESPACE_
+
+
+// === Forward decls ===
+_WINDOWS_NUMERICS_BEGIN_NAMESPACE_ {
+
+  struct float2;
+  struct float3;
+  struct float4;
+  struct float3x2;
+  struct float4x4;
+  struct plane;
+  struct quaternion;
+
+} _WINDOWS_NUMERICS_END_NAMESPACE_
+
+
+// === float2: Struct and function defs ===
+_WINDOWS_NUMERICS_BEGIN_NAMESPACE_ {
+
+  struct float2 {
+float2() = default;
+constexpr float2(float x, float y)
+  : x(x), y(y)
+{}
+constexpr explicit float2(float val)
+  : x(val), y(val)
+{}
+
+static constexpr float2 zero() {
+  return float2(0.0f);
+}
+static constexpr float2 one() {
+  return float2(1.0f);
+}
+static constexpr float2 unit_x() {
+  return { 1.0f, 0.0f };
+}
+static constexpr float2 unit_y() {
+  return { 0.0f, 1.0f };
+}
+
+float x;
+float 

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

[Alvin Wong via Mingw-w64-public]

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++/WinRT headers, right, 
so it can't rely on those bits - or how is that supposed to work?


It's a bit unclear, but after a bit more investigation it seems to me 
that they are intended for C++/CX interop only (which nothing outside 
of MSVC supports and is also being replaced by C++/WinRT). The bits 
that interop with types in the `Windows::Foundation` namespace are 
provided by the generated bindings from cppwinrt (also for C++/WinRT 
they are in the `winrt::Windows::Foundation` namespace instead). As 
for the bits that interop with types in the 
`Microsoft::Graphics::Canvas::Numerics` namespace... I can only say 
they look like to be Win2D types and I have no clue how they work 
with C++/WinRT.


Perhaps it makes no sense to keep these dummied out declarations. 
Shall I remove them?


Yes, I think it'd make sense to leave them out for now. If they're 
needed it should be easy to readd them from this previous version of 
the patch.


Applying this partial header in this form looks sensible to me; 
someone can easily step up and contribute more things to fill in 
gaps as time allows and/or needs arise.


One problem is that this makes it difficult for users to detect 
whether the windowsnumerics.h support is complete. Without the header 
file, users can use the PP macro `__has_include` to disable code that 
relies on windowsnumerics.h. But if an incomplete windowsnumerics.h 
is shipped then it may become messy... This partial header does work 
for my current use case, which is only to make the relevant cppwinrt 
tests pass, but I am having second thoughts about actually shipping 
it to everyone in this state. Maybe better if we hide it behind an 
experimental feature somehow (is this possible?)


I'm not sure if there's any good way of doing this - especially if the 
way uesrs check for it is with __has_include, then there's little we 
can do short of omitting the file unless mingw-w64-headers is built 
with --enable-incomplete-windowsnumerics or something such.


So I don't think worth the extra complication. Or are you aware of 
concrete cases where third party code uses 
__has_include()?


Also, many mingw-w64 headers have this issue in principle - we kinda 
know that they're possibly incomplete, but they cover the known 
relevant parts of the APIs at least.


The cppwinrt headers does `#if __has_include()` 
(which I need to make PR to change it to lowercase but that's another 
matter). It only uses the types and their fields to implement the type 
conversions so it is not affected by any of the undefined functions.


I don't know if there are other code which does that. If you think this 
isn't an issue worth worrying about then I'm fine with it too.



Additionally for this header, filling in gaps should be fairly 
straightforward (especially if there are clear TODO markings that list 
what you know is omitted). I'm considering picking up that task, just 
for the sense of completeness ;-)


Although the matrix math seems to be using an assumption of matrices 
which is transposed from how OpenGL conventionally sets things up, and 
I'm only familiar with that form, so it forces me to think some things 
differently.


Your work will certainly be appreciated :D Though it is not in any way 
high priority so please don't let this take too much of your time.


These probably use the same arrangement as DirectX because they are 
supposed to interop in some way.




___
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 windowsnumerics.h, windowsnumerics.impl.h

[Alvin Wong via Mingw-w64-public]

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 defined. Attempting to use
the undefined functions will likely produce a compiler warning followed
by a linker error.
---
There are too much vector and matrix maths for me to implement, so I 
would like to send in a partial implementation and hope that someone 
else will pick it up and finish the remaining functions.
The patch includes a test program which I used to smoke test the 
functions currently implemented.


This looks great to me overall, nothing very particular to add about it.


Thanks for the review.


About the WinRT interop functions - how are they supposed to be 
provided? This header is layered under the C++/WinRT headers, right, 
so it can't rely on those bits - or how is that supposed to work?


It's a bit unclear, but after a bit more investigation it seems to me 
that they are intended for C++/CX interop only (which nothing outside of 
MSVC supports and is also being replaced by C++/WinRT). The bits that 
interop with types in the `Windows::Foundation` namespace are provided 
by the generated bindings from cppwinrt (also for C++/WinRT they are in 
the `winrt::Windows::Foundation` namespace instead). As for the bits 
that interop with types in the `Microsoft::Graphics::Canvas::Numerics` 
namespace... I can only say they look like to be Win2D types and I have 
no clue how they work with C++/WinRT.


Perhaps it makes no sense to keep these dummied out declarations. Shall 
I remove them?



Applying this partial header in this form looks sensible to me; 
someone can easily step up and contribute more things to fill in gaps 
as time allows and/or needs arise.


One problem is that this makes it difficult for users to detect whether 
the windowsnumerics.h support is complete. Without the header file, 
users can use the PP macro `__has_include` to disable code that relies 
on windowsnumerics.h. But if an incomplete windowsnumerics.h is shipped 
then it may become messy... This partial header does work for my current 
use case, which is only to make the relevant cppwinrt tests pass, but I 
am having second thoughts about actually shipping it to everyone in this 
state. Maybe better if we hide it behind an experimental feature somehow 
(is this possible?)



The testcase has some trailing whitespace, and one surprising tab for 
indentation in the main function, but these are simple to fix up 
before pushing.


Ack, I'll reformat the file.



___
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/ssp: Use different __fastfail code in __chk_fail

[Alvin Wong via Mingw-w64-public]

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/mingw-w64-crt/ssp/chk_fail.c
index b77213904..b577219a8 100644
--- a/mingw-w64-crt/ssp/chk_fail.c
+++ b/mingw-w64-crt/ssp/chk_fail.c
@@ -15,7 +15,7 @@ void __cdecl __attribute__((__noreturn__)) __chk_fail(void) {
   static const char msg[] = "*** buffer overflow detected ***: terminated\n";
   write(STDERR_FILENO, msg, strlen(msg));
   if (IsProcessorFeaturePresent(PF_FASTFAIL_AVAILABLE)) {
-__fastfail(FAST_FAIL_STACK_COOKIE_CHECK_FAILURE);
+__fastfail(FAST_FAIL_RANGE_CHECK_FAILURE);
   } else {
 TerminateProcess(GetCurrentProcess(), STATUS_STACK_BUFFER_OVERRUN);
 __builtin_unreachable();
-- 
2.37.1



___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Alvin Wong via Mingw-w64-public]

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" {
  #define _ungettc ungetwc
  #define _ungettch _ungetwch
  
+#define _tcstof wcstof

  #define _tcstod wcstod
  #define _tcstol wcstol
  #define _tcstoul wcstoul
@@ -218,6 +219,7 @@ extern "C" {
  #define _tstol _wtol
  #define _tstoi _wtoi
  #define _tstoi64 _wtoi64
+#define _tcstof_l _wcstof_l
  #define _tcstod_l _wcstod_l
  #define _tcstol_l _wcstol_l
  #define _tcstoul_l _wcstoul_l
`_wcstof_l` isn't currently declared in `stdlib.h` and `wchar.h`, so 
you'll need to add it too.




___
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: Add windowsnumerics.h, windowsnumerics.impl.h

[Alvin Wong via Mingw-w64-public]

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 error.
---
There are too much vector and matrix maths for me to implement, so I 
would like to send in a partial implementation and hope that someone 
else will pick it up and finish the remaining functions.
The patch includes a test program which I used to smoke test the 
functions currently implemented.From d3df06afe7906edc3776f2fa594b0298278e615c Mon Sep 17 00:00:00 2001
From: Alvin Wong 
Date: Thu, 20 Oct 2022 23:15:47 +0800
Subject: [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 error.

Signed-off-by: Alvin Wong 
---
 mingw-w64-headers/include/windowsnumerics.h   |   30 +
 .../include/windowsnumerics.impl.h| 1089 +
 .../testcases/test_windowsnumerics.cpp|  929 ++
 3 files changed, 2048 insertions(+)
 create mode 100644 mingw-w64-headers/include/windowsnumerics.h
 create mode 100644 mingw-w64-headers/include/windowsnumerics.impl.h
 create mode 100644 mingw-w64-headers/testcases/test_windowsnumerics.cpp

diff --git a/mingw-w64-headers/include/windowsnumerics.h 
b/mingw-w64-headers/include/windowsnumerics.h
new file mode 100644
index 0..e97086538
--- /dev/null
+++ b/mingw-w64-headers/include/windowsnumerics.h
@@ -0,0 +1,30 @@
+/**
+ * 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 _WINDOWSNUMERICS_
+#define _WINDOWSNUMERICS_
+
+#ifndef __cplusplus
+#error windowsnumerics.h requires C++
+#endif /* __cplusplus */
+
+#define _WINDOWS_NUMERICS_NAMESPACE_ Windows::Foundation::Numerics
+
+#define _WINDOWS_NUMERICS_BEGIN_NAMESPACE_ \
+  namespace Windows { \
+namespace Foundation { \
+  namespace Numerics
+
+#define _WINDOWS_NUMERICS_END_NAMESPACE_ \
+} \
+  }
+
+#include "windowsnumerics.impl.h"
+
+#undef _WINDOWS_NUMERICS_NAMESPACE_
+#undef _WINDOWS_NUMERICS_BEGIN_NAMESPACE_
+#undef _WINDOWS_NUMERICS_END_NAMESPACE_
+
+#endif /* _WINDOWSNUMERICS_ */
diff --git a/mingw-w64-headers/include/windowsnumerics.impl.h 
b/mingw-w64-headers/include/windowsnumerics.impl.h
new file mode 100644
index 0..abb8686db
--- /dev/null
+++ b/mingw-w64-headers/include/windowsnumerics.impl.h
@@ -0,0 +1,1089 @@
+/**
+ * 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.
+ */
+
+/**
+ * Normal users should include `windowsnumerics.h` instead of this header.
+ * However, the cppwinrt headers set `_WINDOWS_NUMERICS_NAMESPACE_`,
+ * `_WINDOWS_NUMERICS_BEGIN_NAMESPACE_` and `_WINDOWS_NUMERICS_END_NAMESPACE_`
+ * to custom values and include `windowsnumerics.impl.h`. Therefore this shall
+ * be considered a public header, and these macros are public API.
+*/
+
+
+#ifdef min
+#  pragma push_macro("min")
+#  undef min
+#  define _WINDOWS_NUMERICS_IMPL_PUSHED_MIN_
+#endif
+
+#ifdef max
+#  pragma push_macro("max")
+#  undef max
+#  define _WINDOWS_NUMERICS_IMPL_PUSHED_MAX_
+#endif
+
+#include 
+#include 
+
+#include "directxmath.h"
+
+
+// === Internal macros ===
+#define _WINDOWS_NUMERICS_IMPL_ASSIGN_OP(_ty1, _op, _ty2) \
+  inline _ty1  _op ## =(_ty1 , _ty2 val2) { \
+val1 = operator _op (val1, val2); \
+return val1; \
+  }
+
+// This hides unimplemented WinRT interop members.
+#define _WINDOWS_NUMERICS_IMPL_HAS_WINRT_INTEROP_ 0
+
+
+// === Internal functions ===
+_WINDOWS_NUMERICS_BEGIN_NAMESPACE_ {
+  namespace _impl {
+
+#if 0 && defined(__cpp_lib_clamp)
+using std::clamp;
+#else
+constexpr const float (const float , const float , const 
float ) {
+  return val < min ? min : (val > max ? max : val);
+}
+#endif
+
+#if 0 && defined(__cpp_lib_interpolate)
+using std::lerp;
+#else
+constexpr float lerp(float val1, float val2, float amount) {
+  // Don't do (val2 - val1) * amount + val1 as it has worse precision.
+  return val2 * amount + val1 * (1.0f - amount);
+}
+#endif
+
+  }
+} _WINDOWS_NUMERICS_END_NAMESPACE_
+
+
+// === Forward decls ===
+_WINDOWS_NUMERICS_BEGIN_NAMESPACE_ {
+
+  struct float2;
+  struct float3;
+  struct float4;
+  struct float3x2;
+  struct float4x4;
+  struct plane;
+  struct quaternion;
+
+} _WINDOWS_NUMERICS_END_NAMESPACE_
+
+
+// === float2: Struct and function defs ===

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

[Alvin Wong via Mingw-w64-public]

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-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Alvin Wong via Mingw-w64-public]

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, which I don't feel like handling right now. If someone else would 
like to look into it, please do.


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-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Alvin Wong via Mingw-w64-public]

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/ctxtcall.h
+++ b/mingw-w64-headers/include/ctxtcall.h
@@ -57,6 +57,9 @@ extern "C"{
   public:
 virtual HRESULT WINAPI ContextCallback(PFNCONTEXTCALL 
pfnCallback,ComCallData *pParam,REFIID riid,int iMethod,IUnknown *pUnk) = 0;
   };
+#ifdef __CRT_UUID_DECL
+  
__CRT_UUID_DECL(IContextCallback,0x01da,0x,0x,0xc0,0x00,0x00,0x00,0x00,0x00,0x00,0x46)
+#endif
 #else
   typedef struct IContextCallbackVtbl {
 BEGIN_INTERFACE
-- 
2.37.1



___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Alvin Wong via Mingw-w64-public]

---
 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 @@ extern "C" {
   extern const CLSID CLSID_Picture_Dib;
   extern const GUID GUID_TRISTATE;
 
+  extern const CLSID CLSID_ContextSwitcher;
+
 #ifdef __cplusplus
 }
 #endif
-- 
2.37.1



___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Alvin Wong via Mingw-w64-public]

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 insertions(+)
 create mode 100644 mingw-w64-crt/libsrc/ctxtcall-uuid.c

diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index 053eab3cf..52b2a06f0 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -140,6 +140,7 @@ src_adsiid=libsrc/activeds-uuid.c
 
 src_libuuid=\
   libsrc/ativscp-uuid.c   libsrc/atsmedia-uuid.clibsrc/bth-uuid.c 
libsrc/cguid-uuid.c libsrc/comcat-uuid.c   \
+  libsrc/ctxtcall-uuid.c \
   libsrc/devguid.clibsrc/docobj-uuid.c  libsrc/dxva-uuid.c
libsrc/exdisp-uuid.clibsrc/extras-uuid.c   \
   libsrc/fwp-uuid.c   libsrc/guid_nul.c libsrc/hlguids-uuid.c 
libsrc/hlink-uuid.c libsrc/mlang-uuid.c\
   libsrc/msctf-uuid.c libsrc/mshtmhst-uuid.clibsrc/mshtml-uuid.c  
libsrc/msxml-uuid.c libsrc/netcfg-uuid.c   \
diff --git a/mingw-w64-crt/libsrc/ctxtcall-uuid.c 
b/mingw-w64-crt/libsrc/ctxtcall-uuid.c
new file mode 100644
index 0..0274b4868
--- /dev/null
+++ b/mingw-w64-crt/libsrc/ctxtcall-uuid.c
@@ -0,0 +1,18 @@
+/**
+ * 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.
+ */
+
+#define INITGUID
+#include 
+
+// These IIDs are used for IContextCallback::ContextCallback (ctxtcall.h)
+// according to various sources.
+
+DEFINE_GUID(IID_IContextCallback,0x01da,0x,0x,0xc0,0x00,0x00,0x00,0x00,0x00,0x00,0x46);
+DEFINE_GUID(IID_ICallbackWithNoReentrancyToApplicationSTA,0x0a299774,0x3e4e,0xfc42,0x1d,0x9d,0x72,0xce,0xe1,0x05,0xca,0x57);
+DEFINE_GUID(IID_IEnterActivityWithNoLock,0xd7174f82,0x36b8,0x4aa8,0x80,0x0a,0xe9,0x63,0xab,0x2d,0xfa,0xb9);
+
+// This CLSID is used to create IContextCallback.
+DEFINE_GUID(CLSID_ContextSwitcher,0x034e,0x,0x,0xc0,0x00,0x00,0x00,0x00,0x00,0x00,0x46);
-- 
2.37.1



___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Alvin Wong via Mingw-w64-public]

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|  1 +
 mingw-w64-crt/libarm64/Makefile.am |  1 +
 5 files changed, 17 insertions(+), 1 deletion(-)
 rename mingw-w64-crt/{libarm32 => lib-common}/xmllite.def (89%)
 create mode 100644 mingw-w64-crt/lib32/xmllite.def

diff --git a/mingw-w64-crt/libarm32/xmllite.def 
b/mingw-w64-crt/lib-common/xmllite.def
similarity index 89%
rename from mingw-w64-crt/libarm32/xmllite.def
rename to mingw-w64-crt/lib-common/xmllite.def
index 2cf21b845..a99294bd6 100644
--- a/mingw-w64-crt/libarm32/xmllite.def
+++ b/mingw-w64-crt/lib-common/xmllite.def
@@ -1,7 +1,7 @@
 ;
 ; Definition file of XmlLite.dll
 ; Automatic generated by gendef
-; written by Kai Tietz 2008-2014
+; written by Kai Tietz 2008
 ;
 LIBRARY "XmlLite.dll"
 EXPORTS
diff --git a/mingw-w64-crt/lib32/Makefile.am b/mingw-w64-crt/lib32/Makefile.am
index cfc8ce610..4bfa4ee61 100644
--- a/mingw-w64-crt/lib32/Makefile.am
+++ b/mingw-w64-crt/lib32/Makefile.am
@@ -359,4 +359,5 @@ lib32_DATA += %reldir%/libxinput1_2.a
 lib32_DATA += %reldir%/libxinput1_3.a
 lib32_DATA += %reldir%/libxinput1_4.a
 lib32_DATA += %reldir%/libxinput9_1_0.a
+lib32_DATA += %reldir%/libxmllite.a
 lib32_DATA += %reldir%/libwindowsapp.a
diff --git a/mingw-w64-crt/lib32/xmllite.def b/mingw-w64-crt/lib32/xmllite.def
new file mode 100644
index 0..0ae34b512
--- /dev/null
+++ b/mingw-w64-crt/lib32/xmllite.def
@@ -0,0 +1,13 @@
+;
+; Definition file of XmlLite.dll
+; Automatic generated by gendef
+; written by Kai Tietz 2008
+;
+LIBRARY "XmlLite.dll"
+EXPORTS
+CreateXmlReader@12
+CreateXmlReaderInputWithEncodingCodePage@24
+CreateXmlReaderInputWithEncodingName@24
+CreateXmlWriter@12
+CreateXmlWriterOutputWithEncodingCodePage@16
+CreateXmlWriterOutputWithEncodingName@16
diff --git a/mingw-w64-crt/lib64/Makefile.am b/mingw-w64-crt/lib64/Makefile.am
index 4a7ef9318..c4db729fe 100644
--- a/mingw-w64-crt/lib64/Makefile.am
+++ b/mingw-w64-crt/lib64/Makefile.am
@@ -831,3 +831,4 @@ lib64_DATA += %reldir%/libsynchronization.a
 lib64_DATA += %reldir%/libwindowsapp.a
 lib64_DATA += %reldir%/libwscapi.a
 lib64_DATA += %reldir%/libwslapi.a
+lib64_DATA += %reldir%/libxmllite.a
diff --git a/mingw-w64-crt/libarm64/Makefile.am 
b/mingw-w64-crt/libarm64/Makefile.am
index 689aee348..07a8968e3 100644
--- a/mingw-w64-crt/libarm64/Makefile.am
+++ b/mingw-w64-crt/libarm64/Makefile.am
@@ -354,3 +354,4 @@ libarm64_DATA += %reldir%/libwsock32.a
 libarm64_DATA += %reldir%/libwtsapi32.a
 libarm64_DATA += %reldir%/libxaudio2_8.a
 libarm64_DATA += %reldir%/libxinput1_4.a
+libarm64_DATA += %reldir%/libxmllite.a
-- 
2.37.1



___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Alvin Wong via Mingw-w64-public]

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);
> +NTSTATUS (WINAPI *pBCryptCloseAlgorithmProvider)(BCRYPT_ALG_HANDLE, 
> ULONG);
> +pBCryptOpenAlgorithmProvider = (void*)GetProcAddress(bcrypt, 
> "BCryptOpenAlgorithmProvider");
> +pBCryptGenRandom = (void*)GetProcAddress(bcrypt, "BCryptGenRandom");
> +pBCryptCloseAlgorithmProvider = (void*)GetProcAddress(bcrypt, 
> "BCryptCloseAlgorithmProvider");
> +
> +if (pBCryptOpenAlgorithmProvider && pBCryptGenRandom && 
> pBCryptCloseAlgorithmProvider) {
> +  BCRYPT_ALG_HANDLE alg;
> +  if (BCRYPT_SUCCESS(pBCryptOpenAlgorithmProvider(, 
> BCRYPT_RNG_ALGORITHM, MS_PRIMITIVE_PROVIDER, 0))) {
> +pBCryptGenRandom(alg, (void*)&__stack_chk_guard, 
> sizeof(__stack_chk_guard), 0);
Should this also check the status result of pBCryptGenRandom(...)?
> +pBCryptCloseAlgorithmProvider(alg, 0);
> +FreeLibrary(bcrypt);
> +return;
> +  }
> +}
> +FreeLibrary(bcrypt);
> +  }
>


___
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 3/4] crt: Provide the stack protector functions/variables in libmingwex too

[Alvin Wong via Mingw-w64-public]

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(, NULL, NULL, PROV_RSA_FULL, 
> CRYPT_VERIFYCONTEXT | CRYPT_SILENT)) {
> +if (CryptGenRandom(crypt, sizeof(__stack_chk_guard), (BYTE*) 
> &__stack_chk_guard) && __stack_chk_guard != 0) {
> +  CryptReleaseContext(crypt, 0);
> +  return;
> +}
> +CryptReleaseContext(crypt, 0);
> +  }

I guess this is just following whatever libssp does, but I did just stumble 
across some talks about RNG functions elsewhere, mainly an old comment on 
Mozilla's bugzilla  
recommending `RtlGenRandom` over `CryptGenRandom` and a discussion in 
rust-random  advocating for 
`BCryptGenRandom` over `RtlGenRandom` and its references. Firefox, Chrome, Rust 
and Go all prefer to use `RtlGenRandom` instead of `CryptGenRandom`. The 
documentation of CryptGenRandom 

 says the API is deprecated and may be removed in the future (though I doubt 
they will really remove it) which may be a good reason to avoid using 
`CryptGenRandom`.

Now whether to use `RtlGenRandom` or `BCryptGenRandom` as the replacement: For 
UWP, `BCryptGenRandom` is the only choice. For desktop, a comment in a 
BoringSSL issue  
claims that they both use "the same internal RNG infrastructure".

It seems we'd be better off replacing this use of `CryptGenRandom` with 
`RtlGenRandom` for desktop and `BCryptGenRandom` for UWP. Do you think this 
make sense?

> +  /* Didn't manage to initialize to a strong random value; set any
> +   * nonzero pointer instead. */
> +  __stack_chk_guard = (void*)0xdeadbeef;
> +}

This should probably set a 64-bit value on 64-bit architectures.

Best Regards,
Alvin



___
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 v3] crt: Add support for Control Flow Guard

[Alvin Wong via Mingw-w64-public]

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-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 `libmingwex.a` to support CFGuard:
>>>
>>> - `mingw_cfguard_support.c` contains the guard check and dispatch
>>>  function pointers and their backward compatible no-op.
>>>  * This object will be built regardless of the `--enable-cfguard`
>>>    option, to allow linking CFGuard-enabled objects to a mingw-w64-crt
>>>    built without CFGuard (the guard checks will effectively become
>>>    no-ops.)
>>> - `mingw_cfguard_loadcfg.S` contains the definition of a load config
>>>  directory structure with the symbol name `_load_config_used`.
>>>  * This object is only built when `--enable-cfguard` is enabled,
>>>    because mingw-w64 doesn't use the load config directory for
>>>    anything else yet. Checks have been added to LLD 16 such that, if
>>>    CFGuard has been requested but the needed load config data is
>>>    missing, it will emit a warning.
>>>
>>> This change alone is not enough to fully enable CFGuard in user-built
>>> binaries. All other libraries shipped with the toolchain will also need
>>> to be built with `-mguard=cf` to include CFGuard checks. Same goes for
>>> building user code. If the user builds and links an executable without
>>> `-mguard=cf`, it will still run normally but without any of the CFGuard
>>> checks being operational.
>>>
>>> (An exception is the sanitizer libraries -- their API hooking mechanisms
>>> may result in indirect calls that fails CFGuard checks.)
>>>
>>> User code may use the function attribute `__declspec(guard(nocf))`
>>> (supported by Clang 16) to stop CFGuard checks from being added to
>>> indirect calls within one function.
>>>
>>> ===
>>>
>>> CFGuard works by having the compiler insert a check before performing
>>> any indirect calls (which terminates the process if the call target is
>>> invalid). The compiler also has to keep track of all the address-taken
>>> functions, which the linker will then use to assemble a
>>> `GuardCFFunctionTable` to list all valid indirect call target addresses.
>>>
>>> To maintain backward compatibile, the guard check function is referenced
>>> via a function pointer which points to a no-op by default. On systems
>>> supporting CFGuard, the image loader replaces the function pointer with
>>> the address of the actual guard check function.
>>>
>>> For this to work, the metadata is stored in the load config directory
>>> struct. MSVC supplies this struct in vcruntime as a symbol with the name
>>> `_load_config_used`, which the linker takes as the load config
>>> directory. In addition, the linker generates synthetic symbols to be
>>> included in the load config struct. This also works with LLD since it
>>> has implemented this feature.
>>>
>>> The load config directory can be inspected using `llvm-readobj
>>> --coff-load-config file.exe` or `dumpbin.exe /loadconfig file.exe`
>>> (dumpbin.exe is included in MSVC build tools.)
>>>
>>> Further reading:
>>> - Control Flow Guard: 
>>> https://docs.microsoft.com/en-us/windows/win32/secbp/control-flow-guard
>>> - Load config structure: 
>>> https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#the-load-configuration-structure-image-only
>>> - Control Flow Guard metadata: 
>>> https://docs.microsoft.com/en-us/windows/win32/secbp/pe-metadata
>>> - My personal notes on CFGuard: 
>>> https://gist.github.com/alvinhochun/a65e4177e2b34d551d7ecb02b55a4b0a
>>>
>>> Signed-off-by: Alvin Wong 
>>> ---
>>> Reworded the commit message to be a bit clearer on what's included when
>>> the flag is not specified.
>>
>> Great stuff! If the only thing changed is the commit message, then that does 
>> seem good to me. I can go ahead and push this after a day or two, to let 
>> others still chime in, if they would happen to have concerns.
>
> I pushed this now - thanks for your contribution!
>
> // Martin


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Alvin Wong via Mingw-w64-public]

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-headers/crt/_mingw.h.in | 25 +
>  1 file changed, 25 insertions(+)
>
> diff --git a/mingw-w64-headers/crt/_mingw.h.in 
> b/mingw-w64-headers/crt/_mingw.h.in
> index 0ef7ae6ea..087fce88d 100644
> --- a/mingw-w64-headers/crt/_mingw.h.in
> +++ b/mingw-w64-headers/crt/_mingw.h.in
> @@ -577,6 +577,7 @@ extern "C" {
>  
>  
>  #ifdef __MINGW_INTRIN_INLINE
> +
>  #ifdef __has_builtin
>  #define __MINGW_DEBUGBREAK_IMPL !__has_builtin(__debugbreak)
>  #else
> @@ -596,8 +597,32 @@ __MINGW_INTRIN_INLINE void __cdecl __debugbreak(void)
>__asm__ __volatile__("unimplemented");
>  #endif
>  }
> +#endif /* __MINGW_DEBUGBREAK_IMPL == 1 */
> +
> +#ifdef __has_builtin
> +#define __MINGW_FASTFAIL_IMPL !__has_builtin(__fastfail)
> +#else
> +#define __MINGW_FASTFAIL_IMPL 1
>  #endif
> +#if __MINGW_FASTFAIL_IMPL == 1
> +void __cdecl __MINGW_ATTRIB_NORETURN __fastfail(unsigned int code);
> +__MINGW_INTRIN_INLINE void __cdecl __MINGW_ATTRIB_NORETURN 
> __fastfail(unsigned int code)
> +{
> +#if defined(__i386__) || defined(__x86_64__)
> +  __asm__ __volatile__("int {$}0x29"::"c"(code));
> +#elif defined(__arm__)
> +  register unsigned int r0 __asm__("r0") = code;
> +  __asm__ __volatile__("udf #0xfb"::"r"(r0));
> +#elif defined(__aarch64__)
> +  register unsigned int w0 __asm__("w0") = code;
> +  __asm__ __volatile__("brk #0xf003"::"r"(w0));
> +#else
> +  __asm__ __volatile__("unimplemented");
>  #endif
> +}
> +#endif /* __MINGW_FASTFAIL_IMPL == 1 */
> +
> +#endif /* defined(__MINGW_INTRIN_INLINE) */
>  
>  /* mingw-w64 specific functions: */
>  const char *__mingw_get_crt_info (void);


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[Alvin Wong via Mingw-w64-public]

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 `libmingwex.a` to support CFGuard:

- `mingw_cfguard_support.c` contains the guard check and dispatch
  function pointers and their backward compatible no-op.
  * This object will be built regardless of the `--enable-cfguard`
option, to allow linking CFGuard-enabled objects to a mingw-w64-crt
built without CFGuard (the guard checks will effectively become
no-ops.)
- `mingw_cfguard_loadcfg.S` contains the definition of a load config
  directory structure with the symbol name `_load_config_used`.
  * This object is only built when `--enable-cfguard` is enabled,
because mingw-w64 doesn't use the load config directory for
anything else yet. Checks have been added to LLD 16 such that, if
CFGuard has been requested but the needed load config data is
missing, it will emit a warning.

This change alone is not enough to fully enable CFGuard in user-built
binaries. All other libraries shipped with the toolchain will also need
to be built with `-mguard=cf` to include CFGuard checks. Same goes for
building user code. If the user builds and links an executable without
`-mguard=cf`, it will still run normally but without any of the CFGuard
checks being operational.

(An exception is the sanitizer libraries -- their API hooking mechanisms
may result in indirect calls that fails CFGuard checks.)

User code may use the function attribute `__declspec(guard(nocf))`
(supported by Clang 16) to stop CFGuard checks from being added to
indirect calls within one function.

===

CFGuard works by having the compiler insert a check before performing
any indirect calls (which terminates the process if the call target is
invalid). The compiler also has to keep track of all the address-taken
functions, which the linker will then use to assemble a
`GuardCFFunctionTable` to list all valid indirect call target addresses.

To maintain backward compatibile, the guard check function is referenced
via a function pointer which points to a no-op by default. On systems
supporting CFGuard, the image loader replaces the function pointer with
the address of the actual guard check function.

For this to work, the metadata is stored in the load config directory
struct. MSVC supplies this struct in vcruntime as a symbol with the name
`_load_config_used`, which the linker takes as the load config
directory. In addition, the linker generates synthetic symbols to be
included in the load config struct. This also works with LLD since it
has implemented this feature.

The load config directory can be inspected using `llvm-readobj
--coff-load-config file.exe` or `dumpbin.exe /loadconfig file.exe`
(dumpbin.exe is included in MSVC build tools.)

Further reading:
- Control Flow Guard: 
https://docs.microsoft.com/en-us/windows/win32/secbp/control-flow-guard
- Load config structure: 
https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#the-load-configuration-structure-image-only
- Control Flow Guard metadata: 
https://docs.microsoft.com/en-us/windows/win32/secbp/pe-metadata
- My personal notes on CFGuard: 
https://gist.github.com/alvinhochun/a65e4177e2b34d551d7ecb02b55a4b0a

Signed-off-by: Alvin Wong 
---
Reworded the commit message to be a bit clearer on what's included when
the flag is not specified.

 mingw-w64-crt/Makefile.am |  10 +-
 mingw-w64-crt/cfguard/mingw_cfguard_loadcfg.S | 124 ++
 mingw-w64-crt/cfguard/mingw_cfguard_support.c |  58 
 mingw-w64-crt/configure.ac|  16 +++
 4 files changed, 207 insertions(+), 1 deletion(-)
 create mode 100644 mingw-w64-crt/cfguard/mingw_cfguard_loadcfg.S
 create mode 100644 mingw-w64-crt/cfguard/mingw_cfguard_support.c

diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index 23b1ab9f..c8a510c0 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -20,7 +20,7 @@ else
 endif
 
 AM_CPPFLAGS=$(sysincludes)
-AM_CFLAGS=-pipe -std=gnu99 -D_CRTBLD -D_WIN32_WINNT=0x0f00 
-D__MSVCRT_VERSION__=0x700 -D__USE_MINGW_ANSI_STDIO=0 @ADD_C_CXX_WARNING_FLAGS@ 
@ADD_C_ONLY_WARNING_FLAGS@
+AM_CFLAGS=-pipe -std=gnu99 -D_CRTBLD -D_WIN32_WINNT=0x0f00 
-D__MSVCRT_VERSION__=0x700 -D__USE_MINGW_ANSI_STDIO=0 @CFGUARD_CFLAGS@ 
@ADD_C_CXX_WARNING_FLAGS@ @ADD_C_ONLY_WARNING_FLAGS@
 AM_CXXFLAGS=@ADD_C_CXX_WARNING_FLAGS@ @ADD_CXX_ONLY_WARNING_FLAGS@
 CPPFLAGSARM32=-mfpu=vfpv3
 CPPFLAGS32=-m32
@@ -490,6 +490,8 @@ src_msvcr120_app=\
 
 # These mingwex sources are target independent:
 src_libmingwex=\
+  cfguard/mingw_cfguard_support.c \
+  \
   crt/dllentry.ccrt/dllmain.c \
   \
   complex/_cabs.ccomplex/cabs.c   complex/cabsf.c   complex/cabsl.c   
complex/cacos.c   complex/cacosf.c   \
@@ -582,6 +584,12 @@ 

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

[Alvin Wong via Mingw-w64-public]

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 the guard check and dispatch
  function pointers and their backward compatible no-op.
- `mingw_cfguard_loadcfg.S` contains the definition of a load config
  directory structure with the symbol name `_load_config_used`.

This change alone is not enough to fully enable CFGuard in user-built
binaries. All other libraries shipped with the toolchain will also need
to be built with `-mguard=cf` to include CFGuard checks. Same goes for
building user code. If the user builds and links an executable without
`-mguard=cf`, it will still run normally but without any of the CFGuard
checks being operational.

(An exception is the sanitizer libraries -- their API hooking mechanisms
may result in indirect calls that fails CFGuard checks.)

User code may use the function attribute `__declspec(guard(nocf))`
(supported by Clang 16) to stop CFGuard checks from being added to
indirect calls within one function.

===

CFGuard works by having the compiler insert a check before performing
any indirect calls (which terminates the process if the call target is
invalid). The compiler also has to keep track of all the address-taken
functions, which the linker will then use to assemble a
`GuardCFFunctionTable` to list all valid indirect call target addresses.

To maintain backward compatibile, the guard check function is referenced
via a function pointer which points to a no-op by default. On systems
supporting CFGuard, the image loader replaces the function pointer with
the address of the actual guard check function.

For this to work, the metadata is stored in the load config directory
struct. MSVC supplies this struct in vcruntime as a symbol with the name
`_load_config_used`, which the linker takes as the load config
directory. In addition, the linker generates synthetic symbols to be
included in the load config struct. This also works with LLD since it
has implemented this feature.

The load config directory can be inspected using `llvm-readobj
--coff-load-config file.exe` or `dumpbin.exe /loadconfig file.exe`
(dumpbin.exe is included in MSVC build tools.)

Further reading:
- Control Flow Guard: 
https://docs.microsoft.com/en-us/windows/win32/secbp/control-flow-guard
- Load config structure: 
https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#the-load-configuration-structure-image-only
- Control Flow Guard metadata: 
https://docs.microsoft.com/en-us/windows/win32/secbp/pe-metadata
- My personal notes on CFGuard: 
https://gist.github.com/alvinhochun/a65e4177e2b34d551d7ecb02b55a4b0a

Signed-off-by: Alvin Wong 
---
 mingw-w64-crt/Makefile.am |  10 +-
 mingw-w64-crt/cfguard/mingw_cfguard_loadcfg.S | 124 ++
 mingw-w64-crt/cfguard/mingw_cfguard_support.c |  58 
 mingw-w64-crt/configure.ac|  16 +++
 4 files changed, 207 insertions(+), 1 deletion(-)
 create mode 100644 mingw-w64-crt/cfguard/mingw_cfguard_loadcfg.S
 create mode 100644 mingw-w64-crt/cfguard/mingw_cfguard_support.c

diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index 23b1ab9f..c8a510c0 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -20,7 +20,7 @@ else
 endif
 
 AM_CPPFLAGS=$(sysincludes)
-AM_CFLAGS=-pipe -std=gnu99 -D_CRTBLD -D_WIN32_WINNT=0x0f00 
-D__MSVCRT_VERSION__=0x700 -D__USE_MINGW_ANSI_STDIO=0 @ADD_C_CXX_WARNING_FLAGS@ 
@ADD_C_ONLY_WARNING_FLAGS@
+AM_CFLAGS=-pipe -std=gnu99 -D_CRTBLD -D_WIN32_WINNT=0x0f00 
-D__MSVCRT_VERSION__=0x700 -D__USE_MINGW_ANSI_STDIO=0 @CFGUARD_CFLAGS@ 
@ADD_C_CXX_WARNING_FLAGS@ @ADD_C_ONLY_WARNING_FLAGS@
 AM_CXXFLAGS=@ADD_C_CXX_WARNING_FLAGS@ @ADD_CXX_ONLY_WARNING_FLAGS@
 CPPFLAGSARM32=-mfpu=vfpv3
 CPPFLAGS32=-m32
@@ -490,6 +490,8 @@ src_msvcr120_app=\
 
 # These mingwex sources are target independent:
 src_libmingwex=\
+  cfguard/mingw_cfguard_support.c \
+  \
   crt/dllentry.ccrt/dllmain.c \
   \
   complex/_cabs.ccomplex/cabs.c   complex/cabsf.c   complex/cabsl.c   
complex/cacos.c   complex/cacosf.c   \
@@ -582,6 +584,12 @@ src_libmingwex=\
   stdio/vscanf.c   stdio/vsnprintf.c stdio/vsnwprintf.c
stdio/vsscanf.c \
   stdio/vswscanf.c stdio/vwscanf.c   stdio/wtoll.c
stdio/mingw_asprintf.cstdio/mingw_vasprintf.c
 
+# Include the default load config struct only for Control Flow Guard support.
+if CFGUARD
+src_libmingwex+=\
+  cfguard/mingw_cfguard_loadcfg.S
+endif
+
 # these go into both 32 and 64 bit x86 versions:
 src_libmingwex_x86=\
   math/x86/_chgsignl.S  math/x86/acosf.c  math/x86/acosh.c 
 math/x86/acosl.c  math/x86/acosh.def.h  \
diff --git a/mingw-w64-crt/cfguard/mingw_cfguard_loadcfg.S 

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

[Alvin Wong via Mingw-w64-public]

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(STDERR_FILENO, msg, strlen(msg));
>>> +  abort();
>>> +}
>>
>> I have a feeling that calling `abort()` may not be the best thing to do 
>> here. From what I recall, `abort` may call `_exit(3)` in some cases (or 
>> perhaps some CRT combinations) and that causes DLLs to be unloaded and 
>> global destructors to be run. In case of a stack smashing event, the process 
>> memory has been corrupted so allowing arbitrary destructors to run could be 
>> a security risk.
>
> Right, that's clearly not ideal. I tested this - on UCRT, abort() doesn't 
> seem to run DLL destructors, while on msvcrt.dll, it does. So we should 
> indeed pick something else.
>
> GCC's libssp calls a createive combo of __builtin_trap(), followed by an 
> explicit invalid write out of bounds, followed by _exit(): 
> https://github.com/gcc-mirror/gcc/blob/releases/gcc-12.2.0/libssp/ssp.c#L158-L178
IIRC __builtin_trap uses ud2 which does trigger the unhandled exception 
handler, which can also run arbitrary user code. Same goes for access 
violation. Not ideal either.
> As we're free to use any Windows specific APIs here, I considered using 
> TerminateProcess() - but I preferred to avoid that as it's not available for 
> older Windows Store apps (targeting Windows 8.x iirc). (We do have a fallback 
> implementation of it for such older Windows Store builds in the 
> winstorecompat library, but there it only boils down to calling _exit().)
>
> But since probably very few do care about those older Windows Store targets 
> at this point, maybe that's not that much of an issue any longer?
>
>> I think MSVC raises fail fast exceptions for all kinds of  security check 
>> failures including /GS buffer security checks. Perhaps the same will be more 
>> appropriate here?
>
> Hmm, I'm not very familiar with those APIs, can you give an example of what 
> that would look like?

Sorry, I got confused -- it's fast fail request instead of fail fast exception. 
There is a compiler intrinsic `__fastfail` [1] designed for this. I believe for 
/GS failure it is called with the code `FAST_FAIL_STACK_COOKIE_CHECK_FAILURE`. 
This intrinsic doesn't seem to be available for mingw-w64 yet but it should be 
simple to implement according to the docs.

(There is a separate API called `RaiseFailFastException` which does different 
things, though it can also bypass unhandled exception handlers.)

But it turns out the __fastfail mechanism is only available starting from 
Windows 8, so it needs a separate code path for Windows 7 or earlier. I had to 
check what MSVC does. The handler is in `vcruntime/gs_report.c`: It first 
checks for __fastfail support using 
`IsProcessorFeaturePresent(PF_FASTFAIL_AVAILABLE)` and use that if true, 
otherwise it does a long fallback routine (at the same time trying to avoid 
overwriting a chunk of the original stack) by manually building a fake 
`EXCEPTION_POINTERS` struct, then calls `SetUnhandledExceptionFilter(NULL)` and 
`UnhandledExceptionFilter(exception_pointers)` to report the exception 
(triggering the default application error message box or the debugger if 
attached), then finally calls `TerminateProcess` as an end. This all seems 
overcomplicated but appears to be needed to break in the debugger or to allow a 
debugger to be attached while bypassing user exception handlers.

I am not sure if it is worth the trouble to reimplement the same fallback 
rather than to just call TerminateProcess (it's only needed <= Win7 so 
shouldn't be a problem for the Windows Store target). RaiseFailFastException 
could be an alternative which does break the debugger, but unfortunately it is 
only available starting from Win7. (Is XP still a supported target?) If you do 
use TerminateProces, the best exit code should be 
`STATUS_SECURITY_CHECK_FAILURE`.

[1]: https://docs.microsoft.com/en-us/cpp/intrinsics/fastfail

Best Regards,
Alvin Wong



___
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/3] crt: Provide the stack protector functions/variables in libmingwex too

[Alvin Wong via Mingw-w64-public]

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 be the best thing to do here. 
From what I recall, `abort` may call `_exit(3)` in some cases (or perhaps some 
CRT combinations) and that causes DLLs to be unloaded and global destructors to 
be run. In case of a stack smashing event, the process memory has been 
corrupted so allowing arbitrary destructors to run could be a security risk.

I think MSVC raises fail fast exceptions for all kinds of  security check 
failures including /GS buffer security checks. Perhaps the same will be more 
appropriate here?

Best Regards,
Alvin Wong



___
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] [RFC] crt: Add support for Control Flow Guard

[Alvin Wong via Mingw-w64-public]

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 this matter!
>
>>
>> This adds support to enable building mingw-w64-crt and user code with
>> Control Flow Gurad using Clang,
>
> Nit: Typo in Guard above.

Noted, will be fixed next time.

>> 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 the guard check and dispatch
>>  function pointers and their backward compatible no-op.
>> - `mingw_cfguard_loadcfg.S` contains the definition of a load config
>>  directory structure with the symbol name `_load_config_used`.
>
> I'm a bit undecided about whether always should add these files, even if the 
> crt files aren't compiled with CFG enabled (for simplicity and robustness 
> maybe).
>
> On the other hand, I thought that leaving it out might be good - that we'd 
> get a linker error if we link with -mguard=cf but the symbol is missing - but 
> apparently lld doesn't error out in that configuration. But with your patch 
> in https://reviews.llvm.org/D133099, we'd at least get a warning in that 
> setting, so I guess this setup, with leaving out the files unless CFG is 
> enabled, makes sense.
> A third thought on the matter: IIRC the _load_config_used structure is used 
> for a bunch of other things too, not only CFG. If other aspects of it would 
> be used in mingw-w64 contexts, I guess we should include it unconditionally?

I don't think the other fields in the load config are useful to mingw-w64 but I 
could be wrong.

I can think of a reason to always include the guard check function pointers in 
mingw_cfguard_support.c -- to support linking to object files compiled with 
-mguard=cf. Actually I think it may be better to always include them.

>> This change alone is not enough to fully enable CFGuard in user-built
>> binaries. All other libraries shipped with the toolchain will also need
>> to be built with `-mguard=cf` to include CFGuard checks. Same goes for
>> building user code.
>
> What happens if you'd have all the necessary structures (_load_config_used 
> etc), but e.g. the crt startup files wouldn't be compiled with -mguard=cf? 
> (What happens both in the simple case if those files don't do any indirect 
> calls - and what happens if they do?)

From within these object files nothing changes. There are no guard checks 
inserted at indirect call sites. If the final executable is linked with CFGuard 
disabled, then the GuardFlags field is not set and the executable should run 
normally without CFGuard.

If the executable is linked with CFGuard enabled: LLD does have a fallback case 
for object files not compiled with -mguard=cf, which takes all relocations and 
treat them as potential call targets to be added to the guard function table. 
This means if any of these function addresses are being passed to other parts 
of the process (e.g. to Windows API) which do perform CFGuard checks, they will 
not fail the check. But this also means there may be more valid call targets 
that malicious parties can potentially abuse in an attack (though it is 
slightly better than without CFGuard at all). It may also give a false sense of 
security since the executable claims to be "CF instrumented", but in fact there 
are no CFGuard checks in certain parts of it.

>> ---
>>
>> CFGuard works by having the compiler insert a check before performing
>> any indirect calls (which terminates the process if the call target is
>> invalid). The compiler also has to keep track of all the address-taken
>> functions, which the linker will then use to assemble a
>> `GuardCFFunctionTable` to list all valid indirect call target addresses.
>>
>> To maintain backward compatibile, the guard check function is referenced
>> via a function pointer which points to a no-op by default. On systems
>> supporting CFGuard, the image loader replaces the function pointer with
>> the address of the actual guard check function.
>>
>> For this to work, the metadata is stored in the load config directory
>> struct. MSVC supplies this struct in vcruntime as a symbol with the name
>> `_load_config_used`, which the linker takes as the load config
>> directory. In addition, the linker generates synthetic symbols to be
>> included in the load config struct. This also works with LLD since it
>> has implemented this feature.
>>
>> The load config directory can be inspected using 

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

[Alvin Wong via Mingw-w64-public]

(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 `-mguard=cf` to CFLAGS,
it also add two new objects to `libmingwex.a`:

- `mingw_cfguard_support.c` contains the guard check and dispatch
  function pointers and their backward compatible no-op.
- `mingw_cfguard_loadcfg.S` contains the definition of a load config
  directory structure with the symbol name `_load_config_used`.

This change alone is not enough to fully enable CFGuard in user-built
binaries. All other libraries shipped with the toolchain will also need
to be built with `-mguard=cf` to include CFGuard checks. Same goes for
building user code. If the user builds and links an executable without
`-mguard=cf`, it will still run normally but without any of the CFGuard
checks being operational.

(An exception is the sanitizer libraries -- their API hooking mechanisms
may result in indirect calls that fails CFGuard checks.)

User code may use the function attribute `__declspec(guard(nocf))`
(supported by Clang 16) to stop CFGuard checks from being added to
indirect calls within one function.

---

CFGuard works by having the compiler insert a check before performing
any indirect calls (which terminates the process if the call target is
invalid). The compiler also has to keep track of all the address-taken
functions, which the linker will then use to assemble a
`GuardCFFunctionTable` to list all valid indirect call target addresses.

To maintain backward compatibile, the guard check function is referenced
via a function pointer which points to a no-op by default. On systems
supporting CFGuard, the image loader replaces the function pointer with
the address of the actual guard check function.

For this to work, the metadata is stored in the load config directory
struct. MSVC supplies this struct in vcruntime as a symbol with the name
`_load_config_used`, which the linker takes as the load config
directory. In addition, the linker generates synthetic symbols to be
included in the load config struct. This also works with LLD since it
has implemented this feature.

The load config directory can be inspected using `llvm-readobj
--coff-load-config file.exe` or `dumpbin.exe /loadconfig file.exe`
(dumpbin.exe is included in MSVC build tools.)

Further reading:
- Control Flow Guard: 
https://docs.microsoft.com/en-us/windows/win32/secbp/control-flow-guard
- Load config structure: 
https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#the-load-configuration-structure-image-only
- Control Flow Guard metadata: 
https://docs.microsoft.com/en-us/windows/win32/secbp/pe-metadata
- My personal notes on CFGuard: 
https://gist.github.com/alvinhochun/a65e4177e2b34d551d7ecb02b55a4b0a

Signed-off-by: Alvin Wong 
---
 mingw-w64-crt/Makefile.am |   8 +-
 mingw-w64-crt/cfguard/mingw_cfguard_loadcfg.S | 118 ++
 mingw-w64-crt/cfguard/mingw_cfguard_support.c |  47 +++
 mingw-w64-crt/configure.ac|  16 +++
 4 files changed, 188 insertions(+), 1 deletion(-)
 create mode 100644 mingw-w64-crt/cfguard/mingw_cfguard_loadcfg.S
 create mode 100644 mingw-w64-crt/cfguard/mingw_cfguard_support.c

diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index 80265711..fef5a0e2 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -20,7 +20,7 @@ else
 endif
 
 AM_CPPFLAGS=$(sysincludes)
-AM_CFLAGS=-pipe -std=gnu99 -D_CRTBLD -D_WIN32_WINNT=0x0f00 
-D__MSVCRT_VERSION__=0x700 -D__USE_MINGW_ANSI_STDIO=0 @ADD_C_CXX_WARNING_FLAGS@ 
@ADD_C_ONLY_WARNING_FLAGS@
+AM_CFLAGS=-pipe -std=gnu99 -D_CRTBLD -D_WIN32_WINNT=0x0f00 
-D__MSVCRT_VERSION__=0x700 -D__USE_MINGW_ANSI_STDIO=0 @CFGUARD_CFLAGS@ 
@ADD_C_CXX_WARNING_FLAGS@ @ADD_C_ONLY_WARNING_FLAGS@
 AM_CXXFLAGS=@ADD_C_CXX_WARNING_FLAGS@ @ADD_CXX_ONLY_WARNING_FLAGS@
 CPPFLAGSARM32=-mfpu=vfpv3
 CPPFLAGS32=-m32
@@ -581,6 +581,12 @@ src_libmingwex=\
   stdio/vscanf.c   stdio/vsnprintf.c stdio/vsnwprintf.c
stdio/vsscanf.c \
   stdio/vswscanf.c stdio/vwscanf.c   stdio/wtoll.c
stdio/mingw_asprintf.cstdio/mingw_vasprintf.c
 
+# Enable only for Control Flow Guard support
+if CFGUARD
+src_libmingwex+=\
+  cfguard/mingw_cfguard_loadcfg.S cfguard/mingw_cfguard_support.c
+endif
+
 # these go into both 32 and 64 bit x86 versions:
 src_libmingwex_x86=\
   math/x86/_chgsignl.S  math/x86/acosf.c  math/x86/acosh.c 
 math/x86/acosl.c  math/x86/acosh.def.h  \
diff --git a/mingw-w64-crt/cfguard/mingw_cfguard_loadcfg.S 
b/mingw-w64-crt/cfguard/mingw_cfguard_loadcfg.S
new file mode 100644
index ..5eb20c71
--- /dev/null
+++ b/mingw-w64-crt/cfguard/mingw_cfguard_loadcfg.S
@@ -0,0 +1,118 @@
+/*
+This assembly source file defines the