writing 0xdeadbeef directly is the worst case we did

Detlef Riekenberg wine.dev at web.de
Sat May 27 09:08:47 CDT 2006


Am Samstag, den 27.05.2006, 01:01 +0200 schrieb Andreas Mohr:

> > I was using 0x00dead00 before, but Dmitry suggested 0xdeadbeef, as this
> > is used in most Places in wine.
> 
> First, then you should really write it as such...

> Second, why does it *ALWAYS* have to be 0xdeadbeef?

It was 0x00dead00 before for winspool.drv/tests.
Dmitry added some tests and he was using 0xdeadbeef.
When i created a Patch to change his 0xdeadbeef to MAGIC_DEAD, he
complained not to do so and to use 0xdeadbeef instead of MAGIC_DEAD.

> In that case there's quite some probability that you have to go on a
> frantic search for the *actual* place that caused Wine to crash with
> a 0xdeadbeef value that's being used *everywhere*...

That's the Main Reason, why writing 0xdeadbeef directly is the worst
case we did.

It was ok, when wine was small, but now, 0xdeadbeef everywhere get
difficult to handle. 

Instead of using 0xdeadbeef directly, we should replace all of them
with MAGIC_DEAD (defined separate in every sourcefile).

When you reach "0xdeadbeaf" in a Bug/Crash, you can change the Value of
MAGIC_DEAD in the possible files and reach the bug. 
(But this does not work anymore for "winspool.drv/tests/" after the
Tests from Dmitry.)

Another solution is using different values (from 0xdead0000 upto
0xdeadffff as Example), then a simple grep give us the file with the
failing statement.
We most not start with 0x0/ 0x8 or 0xc to avoid conflicts with native
return-values.

When writing the magic value directly in the source you see it on every
used location. 
The disadvantage is IMHO more important: Changes are much more complex.
This is the Situation we have reached now.
 

> OK, as an invalid error value during winetests there is no way to mix it up,
> but with vtable values and many, many other places that use it that *is*
> an issue.

YES!
Let's push the Developer in this direction.

(I changed the Subject to get more readers / comments)


-- 
By By ...
      ... Detlef




More information about the wine-devel mailing list