Dalibor Topic wrote:
> David Holmes - Sun Microsystems wrote:
> > > In C, the result of an overflowing add of two signed integers is
> > > undefined.
> >
> > Strewth! That's a surprise to me. I always thought that C defined
> > integer arithmetic to always wrap.
>
> Only for unsigned operands (fro
Martin Buchholz wrote:
> Does this actually change the behavior with recent gccs?
I don't think anything changed recently, not on Intel or SPARC,
but I develop on PowerPC, and GCC on 32-bit PowerPC seems to
overflow to 1, -1 or 0... sometimes. But that's not the point;
the behaviour is undefined,
> >> In C, the result of an overflowing add of two signed integers is
> >> undefined.
>
> Strewth! That's a surprise to me. I always thought that C defined
> integer arithmetic to always wrap. Checking for a negative to detect
> overflow is a common pattern - heck it's THE pattern for detecting
>
> >> In C, the result of an overflowing add of two signed integers is
> >> undefined.
>
> Strewth! That's a surprise to me. I always thought that C defined
> integer arithmetic to always wrap. Checking for a negative to detect
> overflow is a common pattern - heck it's THE pattern for detectin
I have sympathy for Gary's reluctance to use jlong,
even though we all know that here the performance of 64-bit
operands doesn't matter.
I propose an alternate patch, which avoids the overflow problem
by simply rearranging the operands, and adds other pedantic
improvements.
I believe it may not b
