在 2022/9/15 03:29, Martin Storsjö 写道:
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
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 feelin
Hi,
On 14/9/2022 15:33, Martin Storsjö wrote:
> +void __cdecl __attribute__((__noreturn__)) __stack_chk_fail(void) {
> + char msg[] = "*** stack smashing detected ***: terminated\n";
> + write(STDERR_FILENO, msg, strlen(msg));
> + abort();
> +}
I have a feeling that calling `abort()` may not b
On Wed, 14 Sep 2022, LIU Hao wrote:
在 2022-09-14 15:20, Martin Storsjö 写道:
The regular mempcpy declaration is visible even without _GNU_SOURCE,
so this one should match.
Signed-off-by: Martin Storsjö
---
mingw-w64-headers/crt/string.h | 2 --
1 file changed, 2 deletions(-)
Well, `mempc
On Wed, 14 Sep 2022, LIU Hao wrote:
在 2022-09-14 15:33, Martin Storsjö 写道:
+
+void __cdecl __attribute__((__noreturn__)) __chk_fail(void) {
+ char msg[] = "*** buffer overflow detected ***: terminated\n";
+ write(STDERR_FILENO, msg, strlen(msg));
+ abort();
+}
Are there any reasons why `ms
On Wed, 14 Sep 2022, Biswapriyo Nath wrote:
Thanks for the patch. It worked in ucrt and msvcrt x86_64 environments.
But if we consider all four CPU architectures there is some missing
symbols in msvcrt.def.in. It seems that many symbols are specified for
x86_64 only including _set_se_translator
Thanks for the patch. It worked in ucrt and msvcrt x86_64 environments.
But if we consider all four CPU architectures there is some missing
symbols in msvcrt.def.in. It seems that many symbols are specified for
x86_64 only including _set_se_translator. For example,
"?what@exception@@UEBAPEBDXZ" is
在 2022-09-14 15:33, Martin Storsjö 写道:
+
+void __cdecl __attribute__((__noreturn__)) __chk_fail(void) {
+ char msg[] = "*** buffer overflow detected ***: terminated\n";
+ write(STDERR_FILENO, msg, strlen(msg));
+ abort();
+}
Are there any reasons why `msg` is not `static const`? I just had a
在 2022-09-14 15:20, Martin Storsjö 写道:
The regular mempcpy declaration is visible even without _GNU_SOURCE,
so this one should match.
Signed-off-by: Martin Storsjö
---
mingw-w64-headers/crt/string.h | 2 --
1 file changed, 2 deletions(-)
Well, `mempcpy()` is indeed a GNU extension, so `_
oh I can reproduce now on the native windows, seems like a wine bug after all
https://bugs.winehq.org/show_bug.cgi?id=53677
sorry for the noise, and thanks for the help
From: LIU Hao
Sent: Tuesday, September 13, 2022 7:34 AM
To: mingw-w64-public@lists.sourcefor
On Wed, 14 Sep 2022, Biswapriyo Nath wrote:
Thanks for the explanation. I have tried to add the following line in
ucrtbase.def.in
```
_Z18_set_se_translatorPFvjP19_EXCEPTION_POINTERSE == _set_se_translator
```
But the given sample program does not link with `g++ test.cpp`
command. I have to add
Thanks for the explanation. I have tried to add the following line in
ucrtbase.def.in
```
_Z18_set_se_translatorPFvjP19_EXCEPTION_POINTERSE == _set_se_translator
```
But the given sample program does not link with `g++ test.cpp`
command. I have to add `-lucrtbase` option explicitly. Did you mean
s
This is the subset of functions that ends up called when our headers
are used with _FORTIFY_SOURCE defined. This avoids needing to
manually pass -lssp in such build configurations.
Signed-off-by: Martin Storsjö
---
mingw-w64-crt/Makefile.am | 4
mingw-w64-crt/ssp/chk_fail.c| 17 +
Our fortification macros don't wrap these stdio functions (since
there's already lots of variability, whether calling directly to
the CRT's stdio functions, or if calling the __USE_MINGW_ANSI_STDIO
replacements), but this at least provides token implementations
if someone implements fortification o
While the compiler drivers do add -lssp automatically when
linking with -fstack-protector-strong, this also allows relying
entirely on libmingwex. This implementation should be functionally
equivalent to GCC's libssp for a mingw build configuration.
This allows toolchains that don't otherwise use
The regular mempcpy declaration is visible even without _GNU_SOURCE,
so this one should match.
Signed-off-by: Martin Storsjö
---
mingw-w64-headers/crt/string.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/mingw-w64-headers/crt/string.h b/mingw-w64-headers/crt/string.h
index 49027c18d..90
On Wed, 14 Sep 2022, Biswapriyo Nath wrote:
* Sample code (test.cpp):
#include
#include
#include
int main() {
_set_se_translator(NULL);
}
* gcc output: undefined reference to
`__imp__Z18_set_se_translatorPFvjP19_EXCEPTION_POINTERSE'
* clang output: undefined symbol: __declspec(dllimport
17 matches
Mail list logo
