find_device_from_devnode was guarded by HAVE_SYS_INOTIFY_H, alas its
use in process_monitor_event was not, so linking failed.
On the way reduce the scope of a variable (which makes sense per se
and avoids introducing a compiler warning with this change).
--
v2: winebus.sys: Fix the build without HAVE_SYS_INOTIFY_H
winebus.sys: Fix the build without HAVE_SYS_INOTIFY_H
https://gitlab.winehq.org/wine/wine/-/merge_requests/1810
GCC12.2 warns about dereferencing a pointer to RpcPktHdr
while it has been allocated to the size of one of the packet
(hence smaller in some cases).
/home/eric/work/wine/dlls/rpcrt4/rpc_message.c:111:26: warning: array subscript 'RpcPktHdr[0]' is partly outside array bounds of 'unsigned char[24]' [-Warray-bounds]
111 | Header->common.rpc_ver = RPC_VER_MAJOR;
This patch fixes the warnings by accessing the created object
through a pointer to their type (and not through the union).
Notes:
- the 'max(sizeof(...), FIELD_OFFSET(...))' thingie in
RPCRT4_BuildBindNackHeader avoids also a warning as the
FIELD_OFFSET() can be smaller than the size of the structure.
This could be avoided by using a flexible array member for
the 'protocols' field instead of 'protocols[ANYSIZE_ARRAY]'.
- I only changed the allocation routines when the allocated size
is smaller than the union.
If the strategy is validated, one could consider applying the
same allocation strategy to all helpers for symmetry reasons.
Hence the draft status for now, waiting for feedback.
Signed-off-by: Eric Pouech <eric.pouech(a)gmail.com>
--
v2: rpcrt4: Fix GCC12.2 warnings.
rpcrt4: Pass a common header to RPCRT4_BuildCommonHeader.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1545
find_device_from_devnode was guarded by HAVE_SYS_INOTIFY_H, alas its
use in process_monitor_event was not, so linking failed.
On the way reduce the scope of a variable (which makes sense per se
and avoids introducing a compiler warning with this change).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1810
> (The TlsIndex field in the LDR_DATA_TABLE_ENTRY structure appears to be unused except as a flag that the module has TLS (being always set to -1), at least as far back as Windows XP. It is worth mentioning that the WINE implementation of implicit TLS incorrectly uses TlsIndex as the real module TLS index, so it may be unreliable to assume that it is always -1 if you care about working on WINE.)
>
> \- http://www.nynaeve.net/?p=186
and the "links to that article but still doesn't work in wine" award goes to... [the D runtime](https://github.com/dlang/dmd/blob/6bf60ea0eb174631ede0074a77d3898d…! (Admittedly, there aren't too many ways to do what they're trying to do.)
With this, the D runtime will now work in Wine, even if in a dll loaded into an exe with no tls (which gets it the tls index 0)
The changes to the debugger are a bit icky, a possible alternative is to find some other easily-debugger-accessible place to stuff the tls index.
--
v6: ntdll: TlsIndex should not actually contain tls indices
winedbg: Don't expect TlsIndex to contain tls indices
https://gitlab.winehq.org/wine/wine/-/merge_requests/1578