-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2015-01-15 um 12:55 schrieb Alex Henrie:
- DVCOMPRESSIONINFO data[32];
I can't really find any documentation about this. Is there a documented maximum number of elements returned?
- int i, j;
Afaics you can make those unsigned.
- LPWSTR string_loc;
Is the use of the LPFOO type intentional?
- if(GetCompressionTypes(iface, NULL, NULL, NULL, 0) == E_NOTIMPL)
- {
skip("%s: GetCompressionTypes not implemented\n", name);return;- }
I think todo_wine ok(0, "GetCompressionTypes not implemented") is better here, but I don't particularly mind since you remove it in the next patch anyway.
ok(data_size > sizeof(DVCOMPRESSIONINFO) && data_size < sizeof(data) - 1,"%s: tests[%i]: expected data_size between %i and %i got data_size=%i\n",name, i, sizeof(DVCOMPRESSIONINFO), sizeof(data) - 1, data_size);
data_size is unsigned, you should use %u instead of %i. Same for i and j once you change them to unsigned.
string_loc = (LPWSTR)((char*)data + num_elements * sizeof(DVCOMPRESSIONINFO));
It's interesting that native places the string in the same data blob, but it kinda makes sense. I think (WCHAR *)(data + num_elements) or (WCHAR *)&data[num_elements] should work as well.
2015-01-15 5:58 GMT-07:00 Stefan Dösinger stefandoesinger@gmail.com:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2015-01-15 um 12:55 schrieb Alex Henrie:
- DVCOMPRESSIONINFO data[32];
I can't really find any documentation about this. Is there a documented maximum number of elements returned?
It's not documented, but in practice Windows returns 7 elements plus their strings, which comes to DVCOMPRESSIONINFO[16] on English systems and a little less than DVCOMPRESSIONINFO[17] on non-English systems. DVCOMPRESSIONINFO[32] is more than enough, but the tests check for overflow just in case.
- int i, j;
Afaics you can make those unsigned.
OK. In try 3 I'll put i and j with the DWORD declarations.
- LPWSTR string_loc;
Is the use of the LPFOO type intentional?
No, I forgot that Wine doesn't like LPFOO. In try 3 I'll change it to WCHAR*.
ok(data_size > sizeof(DVCOMPRESSIONINFO) && data_size < sizeof(data) - 1,"%s: tests[%i]: expected data_size between %i and %i got data_size=%i\n",name, i, sizeof(DVCOMPRESSIONINFO), sizeof(data) - 1, data_size);data_size is unsigned, you should use %u instead of %i. Same for i and j once you change them to unsigned.
Good point. In try 3 I'll use %u instead of %i.
string_loc = (LPWSTR)((char*)data + num_elements * sizeof(DVCOMPRESSIONINFO));It's interesting that native places the string in the same data blob, but it kinda makes sense. I think (WCHAR *)(data + num_elements) or (WCHAR *)&data[num_elements] should work as well.
Good point. In try 3 I'll change this to (WCHAR*)(data + num_elements).
By the way, you can see my work in progress and comment on it at https://github.com/alexhenrie/wine/commits/master
-Alex
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2015-01-15 um 22:38 schrieb Alex Henrie:
It's not documented, but in practice Windows returns 7 elements plus their strings, which comes to DVCOMPRESSIONINFO[16] on English systems and a little less than DVCOMPRESSIONINFO[17] on non-English systems. DVCOMPRESSIONINFO[32] is more than enough, but the tests check for overflow just in case.
I think allocating this depending on the size returned by windows (+ some extra bytes to check the 0x23 filler) would be cleaner. I don't think the size < sizeof(DVCOMPRESSIONINFO) * 32 has any value other than verifying that the fixed size hasn't been exceeded.
-
Alex Henrie -
Stefan Dösinger