Hey, on that topic, there are also a bunch of other possible suspects:
./dlls/ntdll/tests/atom.c: memset(abi->Name, 0x55, 255 * sizeof(WCHAR)); ./dlls/ntdll/tests/atom.c: memset(abi->Name, 0x55, lstrlenW(testAtom1) * sizeof(WCHAR)); ./dlls/user32/tests/menu.c: memset( bmfill, 0x55, sizeof( bmfill)); ./dlls/ntoskrnl.exe/ntoskrnl.c: memset( &irp, 0x55, sizeof(irp) ); ./tools/wrc/utils.c: memset(res, 0x55, size); ./tools/widl/utils.c: memset(res, 0x55, size); ./tools/wmc/utils.c: memset(res, 0x55, size); ./server/object.c: if (ptr) memset( ptr, 0x55, size ); ./server/window.c: memset( win, 0x55, sizeof(*win) + win->nb_extra_bytes - 1 );
And 0xaa can also interfere:
./dlls/kernel32/tests/process.c: memset(&info, 0xaa, sizeof(info)); ./dlls/ddraw/tests/d3d.c: memset(outH, 0xaa, sizeof(outH)); ./dlls/comctl32/tests/listview.c: memset(&column, 0xaa, sizeof(column)); ./dlls/comctl32/tests/listview.c: memset(&item, 0xaa, sizeof (item)); ./dlls/comctl32/tests/listview.c: memset (&item, 0xaa, sizeof (item)); ./dlls/comctl32/tests/listview.c: memset (&item, 0xaa, sizeof (item)); ./dlls/comctl32/tests/listview.c: memset (&item, 0xaa, sizeof (item)); ./dlls/comctl32/tests/listview.c: memset (&item, 0xaa, sizeof (item)); ./dlls/comctl32/tests/listview.c: memset (&item, 0xaa, sizeof (item)); ./dlls/comctl32/tests/listview.c: memset (&item, 0xaa, sizeof (item)); ./dlls/comctl32/tests/listview.c: memset (&item, 0xaa, sizeof (item)); ./dlls/comctl32/tests/listview.c: memset (&item, 0xaa, sizeof (item)); ./dlls/comctl32/tests/listview.c: memset(&column, 0xaa, sizeof(column)); ./server/object.c: memset( obj, 0xaa, obj->ops->size );
"Dan Kegel" dank@kegel.com wrote:
Hey, on that topic, there are also a bunch of other possible suspects:
./dlls/ntdll/tests/atom.c: memset(abi->Name, 0x55, 255 * sizeof(WCHAR)); ./dlls/ntdll/tests/atom.c: memset(abi->Name, 0x55, lstrlenW(testAtom1) * sizeof(WCHAR)); ./dlls/user32/tests/menu.c: memset( bmfill, 0x55, sizeof( bmfill)); ./dlls/ntoskrnl.exe/ntoskrnl.c: memset( &irp, 0x55, sizeof(irp) ); ./tools/wrc/utils.c: memset(res, 0x55, size); ./tools/widl/utils.c: memset(res, 0x55, size); ./tools/wmc/utils.c: memset(res, 0x55, size); ./server/object.c: if (ptr) memset( ptr, 0x55, size ); ./server/window.c: memset( win, 0x55, sizeof(*win) + win->nb_extra_bytes - 1 );
And 0xaa can also interfere:
Perhaps we could agree on a common constant to mark not initialized data in tests? I'd suggest to use 0xCC (standard debugging trick) for that purpose.
On Mon, 3 Mar 2008, Dmitry Timoshkov wrote: [...]
Perhaps we could agree on a common constant to mark not initialized data in tests? I'd suggest to use 0xCC (standard debugging trick) for that purpose.
I'm open to suggestions. So 0xcc is commonly used for this purpose? If it's used by debuggers wouldn't this be a reason to avoid it?
If I remember correctly a couple of tests need two values and use both 0x55 and 0xaa. Do you have another constant to suggest for this case?
On Sun, 2 Mar 2008, Dan Kegel wrote:
Hey, on that topic, there are also a bunch of other possible suspects:
./dlls/ntdll/tests/atom.c: memset(abi->Name, 0x55, 255 * sizeof(WCHAR)); ./dlls/ntdll/tests/atom.c: memset(abi->Name, 0x55,
[...]
And 0xaa can also interfere:
./dlls/kernel32/tests/process.c: memset(&info, 0xaa, sizeof(info));
[...]
Yes. I have a few other patches (though not for all of them) but I was waiting to see if this one would go through before flooding wine-patches.
-
Dan Kegel -
Dmitry Timoshkov -
Francois Gouget