On Sat, Mar 15, 2008 at 04:47:25PM +0100, Roland Mainz wrote:
> Does anyone know tools to track down problems caused by uninitalised
> global or stack variables except dbx's "check -access" functionality
> (which doesn't work in B84) which work in Solaris 11 ?
gcc -Wuninitialized and lint in "enhanced mode" both do this today.
> BTW: Did anyone thought about adding compiler options yet to initalise
> "uninitalised" variables with a fixed byte sequence (e.g.
> -xinituninitalised=0xdeadbeef will fill all uninitalised memory
> belonging to variables on the stack with the (repeated) sequence
> 0xdeadbeef ; using -xinituninitalised=0xff will write 0xff repeatedly
> into such memory etc.) to make this kind of bug hunt more "predictable"
> ?
Interesting idea. Still, it could greatly reduce performance so you
wouldn't likely want to ship such binaries. Which brings us back to
stuff you do during development, and in nearly all cases the proper
compiler options and/or lint usage will catch the errors. One example
I can think of that will sneak past is something like:
foo.c:
int
foo(int *x)
{
return (0);
}
bar.c:
extern int foo(int *);
int bar(void)
{
int x, y;
...
y = foo(&x);
...
do_something_with_x;
}
Then again, if you give foo the correct signature (extern int
foo(const int *)) then the compiler and lint can do the right thing.
--
Keith M Wesolowski "Sir, we're surrounded!"
Fishworks "Excellent; we can attack in any direction!"
