Hammer on snapshot cd's

[Vincent Stemen]

On Tue, Jul 15, 2008 at 07:34:10PM +0100, Simon 'corecode' Schubert wrote:
> Matthew Dillon wrote:
>> :..
>> :> :
>> :> :>    That is very odd.  Maybe there's a 64-bit arithmatic problem 
>> somewhere
>> :>    w/ gcc-34.
>> :
>> :Hi Matt,
>> :
>> :the following patch fixes the problem for me. Not sure whether it is the
>> :correct solution though.
>> :
>> :Cheers,
>> :Johannes
>> :
>> :Index: hammer_btree.c
>> :+	int error = 0;
>> : 	int r;
>>     Wow.  That is one nasty bug and I am very happy that you found it.
>>     I will fix it right now.
>>     I blame my own convalescence.  I was relying on gcc-4 to warn me about
>>     possible uninitialized variable use and got a bit too fancy in my
>>     handling of 'error' in that routine.  GCC missed a case where I was 
>> not
>>     initializing error in a switch deeper down in that routine.
>
> How the heck can a compiler "miss" this?  I thought whenever there existed 
> a possible execution path which would not initialize the variable, it would 
> complain.
>
> cheers
>   simon

That is what I thought also, but recently I encountered a similar
situation that lead me to believe you cannot always depend on gcc
reporting such issues.  I was working on a set of functions in a file
called query.c.  I was testing before including it in the rest of the
code by compiling it stand alone with a simple main.c that included
query.c, i.e  #include "query.c".  

Compiling with "gcc -o query -g -Wall main.c" produced no warnings at
all.  But when I added #include "query.c" to the main code module after
it was working stand alone,  I got a number of compiler warnings about
possible use of initialized variables in functions that are in query.c.

I still don't know why I got no warnings when it was included in the
main.c test module.

This was with gcc 3.4.6 on DragonFly.