On Fri Jan 19 22:20:34 2024 +0000, Krzysztof Bogacki wrote:
> Indeed, but I thought it would be safer to allocate some memory for a
> temporary working area, try enumerating adapters and only copy the
> result if the entire operation did not fail halfway through rather than
> using the array I was passed by the caller directly and risk writing
> some partially misleading garbage to it. I also wasn't sure how to
> proceed in such case: if I already wrote some LUIDs and handles, should
> I try to `memset(0)` them just in case or leave the data there and trust
> that all callers of this API will ignore whatever was written, treating
> the content as unspecified?
> It's also somewhat tricky to cause Windows to fail here so I don't know
> how exactly does it behave when it encounters some error internally.
> Copying the full result only on full success seemed like an easy way out
> that allowed me to not bother figuring this out, even if it costs an
> extra allocation.
> But I can revert to writing to `pAdapters` directly if you'd prefer it
> that way.
If an error occurs, an error code is returned and the application shouldn't use the buffer. But just to be safe, you can do a memset(0) when it fails.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4857#note_58359
On Fri Jan 19 22:20:33 2024 +0000, Krzysztof Bogacki wrote:
> While two separate Windows machines on which I queried the size of array
> to allocate did return 32, this number isn't something that's documented
> anywhere and probably shouldn't be relied on directly. I can add a test
> that checks that `NumAdapters` is always set to `32` if `pAdapters` is
> `NULL` and it might even pass on most if not all Windows versions
> currently out there but Microsoft could one day decide that in such
> cases `64` should now be returned and there would be nothing wrong with
> that… or so I believe. Otherwise, this is already tested by first
> `ok(enum_adapters_2_desc.NumAdapters, "Expect not zero.\n");`, although
> not very strictly.
> I'm also not sure what would Windows return on systems with more than 32
> adapters. Can Windows even support that many GPUs at the same time?
Let's make the test stricter by comparing it to 32. If the test fails one day, we can enlarge the number.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4857#note_58357
On Fri Jan 19 22:20:33 2024 +0000, Krzysztof Bogacki wrote:
> Together with the +1 above, this was meant to verify that array entries
> past number returned by the call that actually fills them are untouched
> (and +1 was for the case where the implementation returns exactly as
> many adapters as the length of the array that was passed). If you
> believe it's not something worth testing, I'll just remove this and +1 above.
Yes, let's remove these.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4857#note_58356
Clang++ fails to compile Wine's include/winnt.h.
This is caused by Wine defining some function inline, while
the compiler provides an intrinsic version.
This is fine with a C compilation, but fails in a C++ compilation.
This serie fixes the compilation by better detecting the various
cases and giving favor to intrinsic when defined (on clang/clang++).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4884
This will make it possible to move some specific behavior out of the AAC decoder transform, and ultimately make it easier to have a generic audio decoder.
--
v3: mfplat: Support compressed WAVEFORMATEX in MFCreateWaveFormatExFromMFMediaType.
mfplat: Support AAC format attributes in MFInitMediaTypeFromWaveFormatEx.
mfplat/tests: Test MFWaveFormatExConvertFlag_ForceExtensible with HEAACWAVEFORMAT.
mfplat/tests: Add MFInitMediaTypeFromWaveFormatEx tests with HEAACWAVEFORMAT.
mfplat/tests: Test MFInitMediaTypeFromWaveFormatEx wrt MF_MT_FIXED_SIZE_SAMPLES.
include: Add HEAACWAVEINFO and HEAACWAVEFORMAT definitions.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4879