Le 10/03/2012 19:51, Nicolas Le Cam a écrit :
Le 10 mars 2012 17:56, Christian Costatitan.costa@gmail.com a écrit :
Le 09/03/2012 16:11, Nicolas Le Cam a écrit :
Le 9 mars 2012 14:22, Christian Costatitan.costa@gmail.com a écrit :
Le 09/03/2012 14:08, Nicolas Le Cam a écrit :
Le 9 mars 2012 13:39, Christian Costatitan.costa@gmail.com a écrit :
Le 08/03/2012 21:23, Alexandre Julliard a écrit : > Christian Costatitan.costa@gmail.com writes: > >> This should fix the d3dxof problem of bug 12694. > It's broken on 64-bit: > > ../../../../wine/tools/runtest -q -P wine -M d3dxof.dll -T ../../.. -p > d3dxof_test.exe.so ../../../../wine/dlls/d3dxof/tests/d3dxof.c&& > touch > d3dxof.ok > d3dxof.c:578: Test failed: Got size 8, expected 4 > d3dxof.c:597: Test failed: Got size 8, expected 4 > make[1]: *** [d3dxof.ok] Error 2 > I updated my tests and just remember sizeof must no be used in traces. BTW what should it be avoided ?
Christian
Because there's no C89/C90 portable way of printf'ing a size_t.
Ok. Thanks. But that could be done using a variable, right ?
Not really, %llu format specifier is avoided too as it's not much portable.
I meant using an unsigned long variable and %lu. Somethig like that.
Using unsigned long can cause value truncation in some implementations like win64.
I can't imagine sizeof() returning something greater than 4Gb.