On Mon, 15 Sep 2025, Pali Rohár wrote:
Ou. I see. The second test case is crashing inside the UCRT's wcstok()
function. So there is no assert output and because of crash there is
also no other visible output. Normally dr watson would be visible.
After debugging, it looks like that UCRT's wcstok() function does not
accept NULL state when the string is NULL. And is trying to dereference
the *state (which cause NULL dereference and crash). I would propose to
disable the second test case. With that change, the test passed my tests
under UCRT env.
diff --git a/mingw-w64-crt/testcases/t_wcstok_s.c
b/mingw-w64-crt/testcases/t_wcstok_s.c
index a9ce9f3dc9d8..ff02805bd1e6 100644
--- a/mingw-w64-crt/testcases/t_wcstok_s.c
+++ b/mingw-w64-crt/testcases/t_wcstok_s.c
@@ -36,7 +36,9 @@ int main() {
assert(handler_called == 0);
assert(handler_errno == -1);
- /* wcstok for NULL string and state returns NULL and does not set errno
and does not call handler */
+ /* msvcrt wcstok for NULL string and state returns NULL and does not set
errno and does not call handler */
+ /* UCRT wcstok for NULL string expects that the state is non-NULL and
dereference it, so do not call this test for UCRT */
+#ifndef _UCRT
handler_called = 0;
handler_errno = -1;
errno = -1;
@@ -46,6 +48,7 @@ int main() {
assert(errno == -1);
assert(handler_called == 0);
assert(handler_errno == -1);
+#endif
Thanks; this change does fix the failures on UCRT.
On msvcrt, on aarch64 and arm64ec (armv7 untested), it fails like this:
FAIL: t_wcstok_s
================
Assertion failed: handler_called == 1, file ../../testcases/t_wcstok_s.c,
line 75
FAIL t_wcstok_s.exe (exit status: 3)
This looks like that msvcrt.dll's wcstok_s on all platforms is calling
msvcrt.dll's _invalid_parameter which is broken. So the registered
exception handler is not called at all.
Replacing wcstok_s by mingw-w64 emulation also on arm platforms (not
just i386 and x64) could help here. Could you check this change?
This change in itself doesn't seem to be enough to make the tests pass;
they now hang instead.
I (or someone else with access to aarch64 systems) will need to concretely
look into it where it is hanging, unless you telepathically can think of
why this may be. :-) Unfortunately I haven't had time to do that yet, but
I will try to get to it.
// Martin
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
