On Thu, Feb 23, 2017 at 01:22:18AM +0200, Jetro Jormalainen wrote:
> @@ -1308,11 +1308,24 @@ HRESULT WINAPI IDirectInputDevice2WImpl_GetProperty(LPDIRECTINPUTDEVICE8W iface,
> case (DWORD_PTR) DIPROP_USERNAME:
> {
> LPDIPROPSTRING ps = (LPDIPROPSTRING)pdiph;
> + struct DevicePlayer *device_player;
>
> if (pdiph->dwSize != sizeof(DIPROPSTRING)) return DIERR_INVALIDPARAM;
>
> - lstrcpynW(ps->wsz, This->username, sizeof(ps->wsz)/sizeof(WCHAR));
> - break;
> + LIST_FOR_EACH_ENTRY(device_player, &This->dinput->device_players,
> + struct DevicePlayer, entry)
> + {
> + if (IsEqualGUID(&device_player->guid, &This->guid))
> + {
> + if (lstrlenW(device_player->username))
Please use *username instead of strlen in places where we don't
actually care about the string length. Same in the other patch.
> @@ -1390,10 +1403,32 @@ HRESULT WINAPI IDirectInputDevice2WImpl_SetProperty(
> case (DWORD_PTR) DIPROP_USERNAME:
> {
> LPCDIPROPSTRING ps = (LPCDIPROPSTRING)pdiph;
> + struct DevicePlayer *device_player;
> + unsigned char found = 0;
Please use BOOL, TRUE, and FALSE for booleans. Some people use those
symbols for their static analyzers. Same in the other patch.
> @@ -56,6 +57,12 @@ struct dinput_device {
> HRESULT (*create_device)(IDirectInputImpl *dinput, REFGUID rguid, REFIID riid, LPVOID *pdev, int unicode);
> };
>
> +struct DevicePlayer {
> + GUID guid;
"guid" is a little vague. This refers to the specific device instance,
right? Maybe device_guid or instance_guid?
Andrew
On Wed, Feb 22, 2017 at 11:23:08PM +0100, André Hentschel wrote:
> -@ stdcall PlaySound(ptr long long) PlaySoundA
> -@ stdcall PlaySoundA(ptr long long)
> -@ stdcall PlaySoundW(ptr long long)
> +@ stdcall PlaySound(str long long) PlaySoundA
> +@ stdcall PlaySoundA(str long long)
> +@ stdcall PlaySoundW(wstr long long)
The first parameter is not always a string, sometimes it's a resource
identifier or even a raw pointer:
https://msdn.microsoft.com/en-us/library/windows/desktop/dd743679(v=vs.85).…
Andrew
Hello,
I recently noticed that we don't currently get Coverity reports for
files in the test suite. I emailed Amine Khaldi, who does the Coverity
reports, and asked if we could start getting reports on the tests.
Amine made it sound like this had been discussed before and due to the
large volume of reports, there was not interest in getting reports for
anything other than the actual Wine code.
Is there enough interest now to start looking at the test suite
reports? Would it hurt anything to be able to see that information?
-Alex
On 26 February 2017 at 19:55, Józef Kucia <jkucia(a)codeweavers.com> wrote:
> +static BOOL match_nvidia_viewport_subpixel_bits(const struct wined3d_gl_info *gl_info, const char *gl_renderer,
> + enum wined3d_gl_vendor gl_vendor, enum wined3d_pci_vendor card_vendor, enum wined3d_pci_device device)
> +{
> + return gl_vendor == GL_VENDOR_NVIDIA && gl_info->supported[ARB_VIEWPORT_ARRAY];
> +}
If reasonably possible, we'd like to avoid matching on gl_vendor and
the like. It's not the most reliable information we have, and would
prevent the feature from working in the future if the driver is ever
fixed. I'll grant the chances aren't great on the latter, but out of
principle, it should be possible to test if the feature itself is
working.
On Wed, Feb 22, 2017 at 5:01 PM, André Hentschel <nerv(a)dawncrow.de> wrote:
> diff --git a/dlls/iphlpapi/tests/iphlpapi.c b/dlls/iphlpapi/tests/iphlpapi.c
> index e0701a3..2f818ff 100644
> --- a/dlls/iphlpapi/tests/iphlpapi.c
> +++ b/dlls/iphlpapi/tests/iphlpapi.c
> @@ -2067,6 +2067,9 @@ static void test_GetUnicastIpAddressEntry(void)
> if (row.Address.si_family == AF_INET6)
> ok(row.ScopeId.Value == row.Address.Ipv6.sin6_scope_id, "Expected %d, got %d\n",
> row.Address.Ipv6.sin6_scope_id, row.ScopeId.Value);
> + else if (row.DadState == IpDadStateTentative)
> + ok(row.ScopeId.Value == aa->IfIndex, "Expected %d, got %d\n",
> + aa->IfIndex, row.ScopeId.Value);
> else
> ok(row.ScopeId.Value == 0, "Expected 0, got %d\n", row.ScopeId.Value);
> ok(row.CreationTimeStamp.QuadPart, "CreationTimeStamp is 0\n");
It may be bikeshedding but 2 things call my attention. The first is
that ScopeID is a IPv6 only field, it is very weird that Windows is
using it for something. The second is that it may be by chance that
ScopeID matches the interface index, tentative means that the DAD
mechanism is still working into checking the IP in the network, so
ScopeID in such case would be meaningless until it turns into
IpDadStatePreferred or maybe one of the other error states.