hi iustin, On Tue, May 25, 2010 at 08:14:05PM +0200, Iustin Pop wrote: > My point is that, if the behaviour is consistent, and upstream relies on it, > it's not buggy. Buggy is gcc that changes results between -O0 and -O2, and > *only* on arm.
nope.. signed overflows are "undefined behavior". that means it is a bug,
but that you may be fortunate if it doesn't seem to cause a problem.
> > did you try
> > re-running the build with -ftrapv in the cmdline? i'm guessing not...
>
> Are you saying that overflows, under any conditions, are wrong?
yes. signed integer overflows under any condition are problematic, period.
i believe that mr. google will back me up here.
> > or
> > have you also applied the above mentioned patches in the meantime?
>
> I'm missing your two XOR changes patches.
yes, that requires some comment from upstream as i'm hesitant to
introduce some kind of regression with a suboptimal hashing function.
there's a number of googleable bit-mixing functions out there on teh
internetz though and i think most employ a method not too different
from what they're already doing (shifting and xoring), just a bit more
safely.
> I still don't understand why consistent overflow behaviour is wrong, or not
> allowed to be used. As far as I see, upstream relies on the semantics of the
> overflow, and on all platforms (except armel + gcc 4.4) they are consistent.
"seemingly consistant" is not the same thing as "guaranteed by the C
standards to be consistant". and fwiw upstream *is* aware of the problematic
behavior of signed overflow, you can see code+comments in a few places
where they correctly work around it (src/google/protobuf/io/coded_stream.cc
lines 97 and 506, for example).
sean
--
signature.asc
Description: Digital signature
