> I'd also like to see the result of getsockname() on all tested paths.
On Windows, `getsockname` returns -1 with `WSAEINVAL` when called on an AF_UNIX socket. However, the paths you delineate are all valid to `bind` to.
> What protocol do these sockets actually have? I.e. what does SO_PROTOCOL_INFO return for them? 0 is usually a wildcard.
Windows returns the following:
```
dwServiceFlags1: 0x00020026 // (XP1_GUARANTEED_DELIVERY | XP1_GUARANTEED_ORDER | XP1_IFS_HANDLES)
dwServiceFlags2: <reserved>
dwServiceFlags3: <reserved>
dwServiceFlags4: <reserved>
dwProviderFlags: 8
ProviderId: <GUID>
dwCatalogEntryId: 1007
ProtocolChain: { ChainLen: 1, ChainEntries: { 0 } }
iVersion: 2
iAddressFamily: 1
iMaxSockAddr: 110
iMinSockAddr: 2
iSocketType: 1
iProtocol: 0
iProtocolMaxOffset: 0
iNetworkByteOrder: 0
iSecurityScheme: 0
dwMessageSize: 0
dwProviderReserved: <reserved>
szProtocol: AF_UNIX
```
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2786#note_34026
On Fri May 26 18:59:04 2023 +0000, Esme Povirk wrote:
> You'll want to check the length passed in, something like `lret + 1 <
> fit` maybe. We can't assume the string is null-terminated.
Woops, sorry. I didn't think of that
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2865#note_34025
To be merged after !2906.
--
v2: wineoss: Use mmdevapi's AudioClient2.
winecoreaudio: Use mmdevapi's AudioClient2.
winealsa: Use mmdevapi's AudioClient2.
winepulse: Move AudioClient2 into mmdevapi.
wineoss: Use mmdevapi's AudioClient3.
winecoreaudio: Use mmdevapi's AudioClient3.
winealsa: Use mmdevapi's AudioClient3.
winepulse: Move AudioClient3 into mmdevapi.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2907
--
v2: wineoss: Use mmdevapi's AudioClient3.
winecoreaudio: Use mmdevapi's AudioClient3.
winealsa: Use mmdevapi's AudioClient3.
winepulse: Move AudioClient3 into mmdevapi.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2906
Some GStreamer plugins such as openh264 return spurious errors when
running the tests. They pass the tests successfull if we simply ignore
them.
It does not make much difference with returning the error, as they are
not supposed to happen anyway, and most of the time the MFT clients
don't expect or handle errors.
Split from https://gitlab.winehq.org/wine/wine/-/merge_requests/2893 as this is also orthogonal and only fixes the tests when running them with openh264, which is not the case on either the testbot or Gitlab.
--
v2: winegstreamer: Set the default H264 caps profile to "baseline".
winegstreamer: Only warn on wg_transform input buffer push errors.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2899