Interesting C question

From: Sean 'Captain Napalm' Conner <spc_at_conman.org>
Date: Wed Feb 6 18:56:18 2002

It was thus said that the Great Cini, Richard once stated:
>
> When in the MSVC debugger, the undeclared variable has the value
> 0xcccccccc. OK.

  Which is a good value for an x86 based platform. If executed, it maps to
INT 3 (if I remember correctly---it's the break point opcode), plus it is
distinctive to see (in a hex dump) and it's either going to be a very large
unsigned value, or a fair sized negative value and most likely an invalid
address if treated as a pointer, so it's sure to cause all sorts of
interesting problems and results if used.

  In my wrappers for malloc()/free(), if I'm running in debug mode, I will
fill the allocated memory with such a pattern (and add extra space before
and after, so that free() can check to see if this padding has been changed.
That alone has caught quite a few problems). The actual pattern I use
depends upon the system and so far, here is what I have:

#ifdef MIPS
# define PADDING 0xB1
# define NULLP 0xB1B1B1B1
#elif defined I386
# define PADDING 0xCC
# define NULLP 0xCCCCCCCC
#elif defined MC68K
# define PADDING 0xA1
# define NULLP 0xA1A1A1A1
#elif defined RS6000
# define PADDING 0xB1
# define NULLP 0xB1B1B1B1
#else
# error Please define system
#endif

  The MIPS I think it's an undefined opcode, and the MC68K will treat that
as an A-line trap. I will definitely need to add Alpha patterns since I now
have access to such a system.

  -spc (I've picked up a few tricks along the way)
Received on Wed Feb 06 2002 - 18:56:18 GMT