On 29 August 2016 at 23:01, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote:
> + * is transformed, and this vertex is offscreen.·
Trailing whitespace.
As an aside, those float comparisons are probably safe enough, but
perhaps those should use compare_vec4()?
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
https://testbot.winehq.org/JobDetails.pl?Key=25440
Your paranoid android.
=== w1064 (32 bit ddraw1) ===
ddraw1.c:2215: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768).
=== w1064 (64 bit ddraw1) ===
ddraw1.c:2215: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768).
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
https://testbot.winehq.org/JobDetails.pl?Key=25439
Your paranoid android.
=== w1064 (32 bit ddraw1) ===
ddraw1.c:2215: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768).
=== w1064 (64 bit ddraw1) ===
ddraw1.c:2215: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768).
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
https://testbot.winehq.org/JobDetails.pl?Key=25438
Your paranoid android.
=== w1064 (32 bit ddraw1) ===
ddraw1.c:2215: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768).
=== w1064 (64 bit ddraw1) ===
ddraw1.c:2215: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768).
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
https://testbot.winehq.org/JobDetails.pl?Key=25437
Your paranoid android.
=== w1064 (32 bit ddraw1) ===
ddraw1.c:2215: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768).
=== w1064 (64 bit ddraw1) ===
ddraw1.c:2215: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768).
=== w1064 (32 bit d3d) ===
d3d.c:2051: Test failed: Unexpected destination texture level pixels; 2031 differences at 0 level
d3d.c:2051: Test failed: Unexpected destination texture level pixels; 518 differences at 1 level
d3d.c:2051: Test failed: Unexpected destination texture level pixels; 138 differences at 2 level
d3d.c:2051: Test failed: Unexpected destination texture level pixels; 46 differences at 3 level
d3d.c:2235: Test failed: Unexpected destination texture level pixels; 257 differences
d3d.c:2382: Test failed: Unexpected destination texture level pixels; 256 differences at 2 level
d3d.c:2382: Test failed: Unexpected destination texture level pixels; 64 differences at 3 level
d3d.c:2382: Test failed: Unexpected destination texture level pixels; 16 differences at 4 level
d3d.c:2382: Test failed: Unexpected destination texture level pixels; 4 differences at 5 level
Hi,
On Aug 29, 2016, at 6:03 AM, David Lawrie <david.dljunk(a)gmail.com> wrote:
>
> +static void char_device_name_length(IOHIDDeviceRef device, char *name, int max_length)
> +{
> + CFStringRef str = copy_device_name(device);
> + CFIndex len = CFStringGetLength(str);
> +
> + if (name)
> + name[0] = 0;
> +
> + if (max_length >= len)
> + {
> + CFStringGetCString(str,name,max_length,kCFStringEncodingASCII);
> + CFRelease(str);
> + }
> + else
> + {
> + CFStringRef substr = CFStringCreateWithSubstring(kCFAllocatorDefault, str, CFRangeMake(0, max_length));
> + CFRelease(str);
> + CFStringGetCString(substr,name,max_length,kCFStringEncodingASCII);
> + CFRelease(substr);
> + }
> +}
I realize you based this function on code from DInput. Unfortunately, that code is pretty badly broken. CFStringGetLength() returns the length of the string in UTF-16 code units, which is basically the same as WCHARs. It's not meaningful to compare that to a buffer size that's in ASCII chars.
Using ASCII is wrong, too. If the name has any non-ASCII characters in it, the conversion will just fail. Second, it's potentially unnecessarily restrictive. Your device_disabled_registry() function, by virtue of using the "A" variant RegQueryValueEx(), uses the ANSI code page, not ASCII. The ANSI code page could maybe handle more names than ASCII would.
You could get a wide string and then use WideCharToMultiByte() to convert it to CP_ACP, but since you control all of the relevant code, it's just better to work with wide strings throughout. Change your device_disabled_registry() and get_config_key() functions to accept a wide string. Then, you can safely use CFStringGetLength() and CFStringGetCharacters() to acquire the WCHAR-based wide string from the CFString. You can just cast a WCHAR* to a UniChar*.
-Ken
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
https://testbot.winehq.org/JobDetails.pl?Key=25430
Your paranoid android.
=== w864 (32 bit rpc) ===
rpc.c:815: Test failed: GUID does not appear to contain a MAC address: {9d7329b2-6dfd-11e6-be78-e71666c2e04a}
=== w864 (64 bit rpc) ===
rpc.c:815: Test failed: GUID does not appear to contain a MAC address: {cfff88a2-6dfd-11e6-be78-e71666c2e04a}
=== w8 (32 bit server) ===
server.c:1010: Test failed: get_ranged_enum() returned 2000814083 instead of RE3
=== w864 (32 bit server) ===
server.c:1010: Test failed: get_ranged_enum() returned 2009071619 instead of RE3
server.c:1010: Test failed: get_ranged_enum() returned 2009071619 instead of RE3
server.c:1010: Test failed: get_ranged_enum() returned 2009071619 instead of RE3
=== w864 (64 bit server) ===
server.c:1010: Test failed: get_ranged_enum() returned 4390915 instead of RE3
server.c:1010: Test failed: get_ranged_enum() returned 117440515 instead of RE3
server.c:1010: Test failed: get_ranged_enum() returned 4390915 instead of RE3
=== w1064 (64 bit server) ===
server.c:1010: Test failed: get_ranged_enum() returned 6356995 instead of RE3
server.c:1010: Test failed: get_ranged_enum() returned 6029315 instead of RE3
On 28 August 2016 at 16:49, André Hentschel <nerv(a)dawncrow.de> wrote:
> Should fix crashes like:
> https://test.winehq.org/data/a83d5d3b83042d2305de0595c0d03e4e7bf1e29e/xp_wx…
>
Does this happen on any setups that aren't using "VirtualBox Graphics
Adapter" as display driver? I don't think failing the test or skipping
is ultimately much more useful than crashing here, but if it's just
about skipping cleanly I'd rather just blacklist the driver in a way
similar to ddraw_is_warp() in the ddraw tests.