Keith M Wesolowski wrote:
> On Sat, Mar 15, 2008 at 04:47:25PM +0100, Roland Mainz wrote:
[snip]
> > 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.
Right... but in real life not all code is "lint" clean and sometimes
there are simply _time_ constrains for finding and fixing bugs (and
you're paid for killing the particular bug, not cleaning-up someone
else's codebase... ;-( ) ...
> 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.
Note that this fails if function |foo()| is in a different library and
cannot be processed by "lint" (Sun Studio's "cc" has "-xipo" which may
be able to help a bit... but "lint" doesn't have a similar option... ;-(
) ...
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
