This lists all fields of the `struct fd_ops` when object of that type --
`handler_fd_ops` in server/signal.c -- is being initialized.
It looks like field list in initialization of the `handler_fd_ops` in
server/signal.c was out-of-sync for a long time. Take a look, for
example, on patches ad1e0609a0f (server: Get rid of no loner used
cancel_async from fd_ops., 2016-12-01) (which removed "reference" to the
`cancel_async` field correctly, but did not add "references" to the `read`
and `write` fields, for example), or 837b39b2028 (server: Add read and
write fd member functions., 2015-05-05) (which updated `struct fd_ops`
but did not change initialization of the `handler_fd_ops` at all).
Because the main purpose of initialization of the `handler_fd_ops` made in
server/signal.c is to assign address of the `handler_poll_event()`
function to the `poll_event` field, while making all other fields `NULL`ed,
lacking some fields in that initialization is not an error according to
C standard:
> 6.7.11 Initialization
>
> 11 ... If an object that has static or thread storage duration is not
> initialized explicitly, or any object is initialized with an empty
> initializer, then it is subject to default initialization, which
> initializes an object as follows:
>
> - if it has pointer type, it is initialized to a null pointer;
>
> ...
>
> 22 If there are fewer initializers in a brace-enclosed list than there
> are elements or members of an aggregate, or fewer characters in a
> string literal used to initialize an array of known size than there
> are elements in the array, the remainder of the aggregate is subject
> to default initialization.
But to maintain code consistency I believe initialization of the
`handler_fd_ops` object should enumerate all fields of the
`struct fd_ops` type.
No functional changes intended.
```shell
$ ./configure
...
$ make
...
$ ./wine --version
wine-9.6-74-g6a1dab2af04
```
--
v27: Fix initialization of the msg_queue_fd_ops
Fix initialization of the process_fd_ops
Fix initialization of the thread_fd_ops
Fix initialization of the inotify_fd_ops
Fix initialization of the master_socket_fd_ops
Fix initialization of the handler_fd_ops
https://gitlab.winehq.org/wine/wine/-/merge_requests/5503
Based on patch by Gabriel Ivăncescu.
The part allowing properties to disappear as part of enumeration (as well as similar changes from previous MR) is not quite optimal. I think we will want to avoid it once host prototypes are supported.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6167
Because WINENV is limited (32767 bytes), and HOSTENV can be much larger,
a whitelisting approach is used to keep WINENV as small as possible.
Currently, only the following envvars are propagated from the host env to WINENV
WINEPATH, WINEPWD, WINEHOME, WINETEMP, WINETMP, WINEQT_, WINEVK_, WINEXDG_SESSION_TYPE
Moreover, the NIXENV (env for running wine processes - not applications) on the
host system is not produced from WINENV anymore, but the global ENV
is propagated to all wine processes and threads.
This might be an alternative approach to MR!5231, MR!6140, bug #56941
and should provide a more deterministic behaviour of wine, because unrelated
envvars do have no influence on the env for running windows applications.
Initial tests (winemine, notepad, cmd, etc) seem to run fine, but some envvars might need additional
consideration. XVDK_* was mentioned, WINE*, MESA_*, VK_*, QT_*, LIBGL_* are other suspects.
Moreover, this is my first merge request, so your feedback is highly appreciated.
--
v2: remove unused vars
https://gitlab.winehq.org/wine/wine/-/merge_requests/6166
without freetype, some calling return failed, so some value may not be initialized (it initialize by some failed calling and pass argument by point of it), it would cause random crash!
Signed-off-by: Fan WenJie <fanwj(a)mail.ustc.edu.cn>
--
v6: win32u: fix random crash without libfreetype
https://gitlab.winehq.org/wine/wine/-/merge_requests/5957
We can't return the unicode string size, this returns sizes to small
for multi-byte characters.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54295
--
v9: userenv: Fix GetProfilesDirectoryA return value
kernel32: Rework ExpandEnvironmentStringsA to return ansi size and fix corner cases.
kernel32: Rework ExpandEnvironmentStringsW error handling.
ntdll: Rework RtlExpandEnvironmentStrings/_U to account for corner cases.
kernel32: Add ExpandEnvironmentStringsA tests for japanese.
kernel32: Add more tests for ExpandEnvironmentStringsA.
kernel32: Add tests for ExpandEnvironmentStringsW.
ntdll: Add more tests for RtlExpandEnvironmentStrings/_U.
userenv: Add another test for GetProfilesDirectoryA
https://gitlab.winehq.org/wine/wine/-/merge_requests/4045
Because WINENV is limited (32767 bytes), and HOSTENV can be much larger,
a whitelisting approach is used to keep WINENV as small as possible.
Currently, only the following envvars are propagated from the host env to WINENV
WINEPATH, WINEPWD, WINEHOME, WINETEMP, WINETMP, WINEQT_, WINEVK_, WINEXDG_SESSION_TYPE
Moreover, the NIXENV (env for running wine processes - not applications) on the
host system is not produced from WINENV anymore, but the global ENV
is propagated to all wine processes and threads.
This might be an alternative approach to MR!5231, MR!6140, bug #56941
and should provide a more deterministic behaviour of wine, because unrelated
envvars do have no influence on the env for running windows applications.
Initial tests (winemine, notepad, cmd, etc) seem to run fine, but some envvars might need additional
consideration. XVDK_* was mentioned, WINE*, MESA_*, VK_*, QT_*, LIBGL_* are other suspects.
Moreover, this is my first merge request, so your feedback is highly appreciated.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6166