> -Original Message-
> I would like to say the one thing I have not heard through this
> discussion is the real reason why the C standards comittee decided
> signed overflow as being undefined. All I can think of is they were
> thinking of target that do saturation for plus/minus but wrapp
Andrew Pinski writes:
>
> This will always cause a trap on x86, even with -fwrapv so really
> -fwrapv has a bug on x86. I will file this bug sometime later
> tomorrow. Oh and fixing this bug will actually slow down users
> of -fwrapv even more than what it is currently does because
> you c
Paul Eggert <[EMAIL PROTECTED]> writes:
| Here are further patches I checked into the Autoconf documentation to
| reflect today's comments (some of which I received privately). Thanks
| to all of you. The trickiest bit was documenting one simple way to
| reliably detect overflow without converti
Andrew Pinski <[EMAIL PROTECTED]> writes:
| >
| > [EMAIL PROTECTED] (Richard Kenner) writes:
| >
| > >> >> Many portable C programs assume that signed integer overflow wraps
around
| > >> >> reliably using two's complement arithmetic.
| > >> >
| > >>
| > >> I was looking for an adjective that m
Andrew Pinski <[EMAIL PROTECTED]> writes:
> the one thing I have not heard through this
> discussion is the real reason why the C standards comittee decided
> signed overflow as being undefined.
I wasn't there, but my impression is that many of the optimization
issues we've talked about in this t
>
> Here are further patches I checked into the Autoconf documentation to
> reflect today's comments (some of which I received privately). Thanks
> to all of you. The trickiest bit was documenting one simple way to
> reliably detect overflow without converting to unsigned and back.
> (At least,
Paul Eggert wrote:
Andrew Pinski <[EMAIL PROTECTED]> writes:
Let me make the point that signed overflow has been undefined since
before the C standard was finialized and in fact there is a nice
paper/book called "C Traps and Pitfalls[2]" which mentions all of this
back in 1988.
C Traps and Pi
>
> [EMAIL PROTECTED] (Richard Kenner) writes:
>
> >> >> Many portable C programs assume that signed integer overflow wraps
> >> >> around
> >> >> reliably using two's complement arithmetic.
> >> >
> >>
> >> I was looking for an adjective that mean the programs work on a wide
> >> variety of pla
Here are further patches I checked into the Autoconf documentation to
reflect today's comments (some of which I received privately). Thanks
to all of you. The trickiest bit was documenting one simple way to
reliably detect overflow without converting to unsigned and back.
(At least, I hope it's r
[EMAIL PROTECTED] (Richard Kenner) writes:
>> >> Many portable C programs assume that signed integer overflow wraps around
>> >> reliably using two's complement arithmetic.
>> >
>>
>> I was looking for an adjective that mean the programs work on a wide
>> variety of platforms, and "portable" seems
Andrew Pinski <[EMAIL PROTECTED]> writes:
> Let me make the point that signed overflow has been undefined since
> before the C standard was finialized and in fact there is a nice
> paper/book called "C Traps and Pitfalls[2]" which mentions all of this
> back in 1988.
C Traps and Pitfalls, like K&
>
> Wrap-around is very useful for digital signal processing.
Saturation is also very useful for DSPs.
This is why for embedded C[1], they are adding types which the
user is able to decide which behavior they want instead of
just being undefined.
Let me make the point that signed overflow has
Richard Kenner wrote:
A few comments:
Many portable C programs assume that signed integer overflow wraps around
reliably using two's complement arithmetic.
I'd replace "portable C programs" with "widely-used C programs". The normal
use of "portable" means that it conforms to the standard.
Richard Kenner wrote:
A few comments:
Many portable C programs assume that signed integer overflow wraps around
reliably using two's complement arithmetic.
I'd replace "portable C programs" with "widely-used C programs". The normal
use of "portable" means that it conforms to the standard.
> >> Many portable C programs assume that signed integer overflow wraps around
> >> reliably using two's complement arithmetic.
> >
>
> I was looking for an adjective that mean the programs work on a wide
> variety of platforms, and "portable" seems more appropriate than
> "widely-used".
Maybe jus
[EMAIL PROTECTED] (Richard Kenner) writes:
> A few comments:
Thanks for the quick review.
>> Many portable C programs assume that signed integer overflow wraps around
>> reliably using two's complement arithmetic.
>
> I'd replace "portable C programs" with "widely-used C programs". The normal
>
>
> Today I updated the Autoconf manual to contain the following
> description of the current situation with signed integer overflow.
> This section of the manual is intended to advise programmers what to
> do about portable C programs in this area.
>
> I think some discussion along these lines a
A few comments:
> Many portable C programs assume that signed integer overflow wraps around
> reliably using two's complement arithmetic.
I'd replace "portable C programs" with "widely-used C programs". The normal
use of "portable" means that it conforms to the standard.
> Conversely, in at lea
Today I updated the Autoconf manual to contain the following
description of the current situation with signed integer overflow.
This section of the manual is intended to advise programmers what to
do about portable C programs in this area.
I think some discussion along these lines also belongs in
19 matches
Mail list logo
