DragonFly users List (threaded) for 2008-07
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]
Re: Hammer on snapshot cd's
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.
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]