Re: [PATCH (try 2) 1/2] dpvoice/tests: Add GetCompressionTypes tests.
-----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.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJUt7l0AAoJEN0/YqbEcdMwf/sQAIGsh8jbGM7AsbdeHt5uEJUD AGGg9OcqrDnW0PoCd5w36G70tNF/NFMRleNJ0tOL4r3HG8TD16BDXCkxW/U9hR7G 6c+DGAqnOFG0y6CjSAMGSvRh5VZVrD5OlI4XRTNFqYdL1QkVD0yQ/kXQl8YsvMUu x/sWJ1kF4FCcojmmhIP5tSo6AmZJlso18tlOReCBBnHDkdq+0ej8ltR/pG0NmZUp 3eOdSfyHd0Swc9P8nLossRKbieORr88fE0ZUBP7oOtg2JbLfs3l/F4fudbPoMF8v 5JbJXD+KuHdNvGYBJ2ppHEZCUC2ArHEYgMW0m2ffRoWfoXmrJCUE8AnJsyHsjaYI LFRiRGom7kRjoY8fhbTSJWdNTKLbW5swAiCzW7A+NkQvrXn5dcL2kZVpi2Z4x1gu 1JKYmb5G9G6SG+U4wblTWET4RWv5rAzoNeXvDZtznBW/KinnkNX2Ic7kug1/usqj ATJ9q8ARt+3DMPYRonk7sXzFdyRRXhlCROlBvqHBkPitVz3tLxvziB/4C1SZ9ybu wy28DMfEYfwbi/9iQnaHsn+811d7uf85QkKgiV6CBvS8XJ2xVzvHWnSWlbc0wNj1 /Gy5gCuKkluFWbJJjAliAf6+uHIypvBbFr85/Gn3gQy/tNUOH4FFSXPB18XrBXh3 CFH+vOFS/SN8fEA6WOtw =EJNM -----END PGP SIGNATURE-----
2015-01-15 5:58 GMT-07:00 Stefan Dösinger <stefandoesinger(a)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.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJUuUCaAAoJEN0/YqbEcdMwiP0P+wbVHDrq68QSx7OcI1imACyi TGn0buTOETw+2lMg2fZ3D0wDqIzAuTm4HcDLiWhJbDyXDwZlPyA1ILnW7M1sArKQ ztV2GZvhejMlW5zQsHBMhJs2zuu2PAWNX0LeHdVgIbBhbQXZ1G8eTSWYQElndvpR Sv/QiNjLzXpiig8o4B+YMleBwktS9LW2ZsFkhiR1MfIQkVTy4JoiQ9eevfxpxdIj GL/0heh0rVZ7cIncEzYp1S8xo+nWLrot4n6TSVwowONFLVynY/c4Rg37VEAzIO1j 6lZD4xjUyoOs2CiQfVu0NUV2ozheC3gE8ngLFfHAD8FpVHCkXrra/PTBiJ6VQx/4 PIe8xOXAC9/nyC/yF1VOwZhFq61Q6R/qercV7/JysbRa0Fw7Lrb66QDf6SqLG++M DFx5o8YD6p9PWSdIT0VIeJgQIM7Y7pfnGeAeqLINvcAzjxWkcC783gqsuz4a+asq VJh0kxlgrOcq6z7aOcYMx5edcIJ0V8qF5r4992VU4F7ILY1mGSmKMlF81i5cMLAK RauIXdAlzSD9ZG8PvRnn+SBS1bnTwK3SfaZCowxq1FcRPbsjwpJFu/iOq0nI6tbw OAnxtOaH/y961CaJ0t40YOUJO7Nw071oGArn7zJoiKjxj0aruY3CyOsfZ/u9D3tS WJY5w+CpDRMccCQ94jfb =OfyS -----END PGP SIGNATURE-----
participants (2)
-
Alex Henrie -
Stefan Dösinger