Recently I am experimenting with an ASan instrumented Wine build (Details [here](https://gitlab.winehq.org/bernhardu/wine/-/blob/asan-pe_2024-12-29/RE…), which was showing some issues when running the confirmance tests.
ASan got triggered on this `lstrlenW( dst )` because it seems the NormalizeString function does not add a termination if the length of the source string does not include the terminating character.
Because the `ok` statements condition contains `lstrlenW( ptest->expected[i] )` I assume that value is also expected to get printed if the test would fail.
```
ASAN_OPTIONS="allocator_may_return_null=1:halt_on_error=0" wine dlls/kernel32/tests/x86_64-windows/kernel32_test.exe locale
=================================================================
==640==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffffe1dd420 at pc 0x000140117178 bp 0x7ffffe1dd0d0 sp 0x7ffffe1dd118
READ of size 2 at 0x7ffffe1dd420 thread T0
0800:fixme:file:server_get_file_info Unsupported info class e
#0 0x000140117177 in lstrlenW .../wine/include/winbase.h:2921:12
#1 0x00014010d76e in test_NormalizeString .../wine/dlls/kernel32/tests/locale.c:7401:54
#2 0x0001400f0e4c in func_locale .../wine/dlls/kernel32/tests/locale.c:8725:3
#3 0x0001401e6c5e in run_test .../wine/include/wine/test.h:765:5
#4 0x0001401e67a1 in main .../wine/include/wine/test.h:884:12
#5 0x0001401e8113 in mainCRTStartup .../wine/dlls/msvcrt/crt_main.c:58:11
#6 0x6fffffc455ee in BaseThreadInitThunk .../wine/dlls/kernel32/thread.c:61:24
#7 0x6fffffdcaaea in RtlUserThreadStart (C:\windows\system32\ntdll.dll+0x17004aaea)
Address 0x7ffffe1dd420 is located in stack of thread T0 at offset 544 in frame
#0 0x00014010d13f in test_NormalizeString .../wine/dlls/kernel32/tests/locale.c:7212
This frame has 8 object(s):
[32, 544) 'dst' (line 7358) <== Memory access at offset 544 overflows this variable
[608, 609) 'ret' (line 7359)
[624, 628) 'dstlen' (line 7361)
[640, 1664) 'buffer' (line 7620)
[1792, 1798) 'str745' (line 7621)
[1824, 1888) 'srcW' (line 7621)
[1920, 1984) 'dstW' (line 7621)
[2016, 2272) 'resW' (line 7621)
HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
(longjmp, SEH and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow .../wine/include/winbase.h:2921:12 in lstrlenW
Shadow bytes around the buggy address:
0x7ffffe1dd180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x7ffffe1dd200: f1 f1 f1 f1 00 00 00 00 00 00 00 00 00 00 00 00
0x7ffffe1dd280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x7ffffe1dd300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x7ffffe1dd380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x7ffffe1dd400: 00 00 00 00[f2]f2 f2 f2 f2 f2 f2 f2 01 f2 04 f2
0x7ffffe1dd480: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
0x7ffffe1dd500: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
0x7ffffe1dd580: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
0x7ffffe1dd600: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
0x7ffffe1dd680: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==640==ABORTING
```
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7201
If application sends out-of-range values for FFB effects, they become -1, which is undesireable, when -1 is in the physical range of the field and being sent to the device. This patch fixes it, clamping values to the field range. Clamping was earlier implemented [here](https://gitlab.winehq.org/wine/wine/-/blob/wine-6.19/dlls/dinput/effe… in 6.19. Windows does this clamping silently, and doesn't fail `SetParameters` call when values is out of range.
Affected application is Assetto Corsa EVO, which with default settings sends out ConstantForce magnitude under/over [documented](https://learn.microsoft.com/en-us/previous-versions/ms835644(v=… \[-10000, 10000\]. [Link to the discussion with some investigation on Steam](https://steamcommunity.com/app/3058630/discussions/0/756142145462617….
In this submission scaling and clamping were moved to the separate `scale_and_clamp_value` function, which is now called every time from `set_parameter_value`. To avoid regression with sending `-1` for the infinite duration effects, separate function `set_parameter_value_no_scaling` created. Gain values in `hid_joystick_send_device_gain` are also scaled and clamped.
--
v3: dinput: Clamp FFB effect report value to the field range.
dinput/tests: Add more tests for force feedback.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7161
Added Constant Force tests, with out-of-bounds Magnitude levels. Also updated Condition Effect tests, now includes Saturation field being out-of-bounds. Tests are passing on Windows. That required modifying test HID descriptor, to include new effect type (Constant) and usage (Magnitude).
Now we have an option to not clamp specific fields, specifically - Saturation ones.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7161#note_92866
The key change is to never return STATUS_TIMEOUT, and to instead return the result of
NtYieldExecution() if zero timeout was passed, or STATUS_SUCCESS otherwise.
An overview of the correct values for each combination, copied from the test commit:
- Non-alertable, zero timeout: STATUS_SUCCESS or STATUS_NO_YIELD_PERFORMED
- Non-alertable, non-zero timeout: STATUS_SUCCESS
- Alertable, zero timeout: STATUS_SUCCESS, STATUS_NO_YIELD_PERFORMED, or STATUS_USER_APC
- Alertable, non-zero timeout: STATUS_SUCCESS or STATUS_USER_APC
--
v7: ntdll: Fix the return value of NtDelayExecution.
ntdll/tests: Add tests for NtDelayExecution and Sleep(Ex).
https://gitlab.winehq.org/wine/wine/-/merge_requests/7169
The key change is to never return STATUS_TIMEOUT, and to instead return the result of
NtYieldExecution() if zero timeout was passed, or STATUS_SUCCESS otherwise.
An overview of the correct values for each combination, copied from the test commit:
- Non-alertable, zero timeout: STATUS_SUCCESS or STATUS_NO_YIELD_PERFORMED
- Non-alertable, non-zero timeout: STATUS_SUCCESS
- Alertable, zero timeout: STATUS_SUCCESS, STATUS_NO_YIELD_PERFORMED, or STATUS_USER_APC
- Alertable, non-zero timeout: STATUS_SUCCESS or STATUS_USER_APC
--
v6: ntdll: Fix the return value of NtDelayExecution.
ntdll/tests: Add tests for NtDelayExecution and Sleep(Ex).
https://gitlab.winehq.org/wine/wine/-/merge_requests/7169