Thus spake Terry Lambert <[EMAIL PROTECTED]>:
> David Schultz wrote:
> > Thus spake Terry Lambert <[EMAIL PROTECTED]>:
> > > Actually, failure to use optimization suppresses some compilation
> > > warnings, particularly those which normally print from using some
> > > variables without initializing them.
> >
> > I think you're thinking of dataflow analysis, which I believe gcc
> > does with -O and higher optimization levels. So unless you're
> > using -O0, I would expect that you'd get all the warnings you
> > want.
>
> See the thread "Re: tmpfile breakage on setuid executables".
>
> Kris accidently introduced a bug that had to do with whether or
> not a variable was used before it was initialized. The compiler
> didn't complain when he checked it before committing it because
> optimization was off by default; it should have complained, e.g.:
>
> "x.c:9:warning: `foo' might be used uninitialized in this function"
Thanks, I saw that. I'm just pointing out that all you need is -O
to get that warning:
das@bloody-mary:~> cat foo.c
int main() {
int foo;
return foo;
}
das@bloody-mary:~> gcc -o foo foo.c -Wall -O
foo.c: In function `main':
foo.c:2: warning: `foo' might be used uninitialized in this function
<rant>
This is one of those things that gcc3 does pretty well, but Sun's
javac does very badly. First of all, in Java, the above warning
is considered an error (except *maybe* in JDK 1.4, which is broken
and slow on IA64 so I can't use it). Second, the dataflow
analysis in javac is braindead, so the compiler is almost always
wrong. When I get the same warning from gcc, it's usually right
unless interprocedural analysis would be required.
</rant>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
