On Jun 29, 2005, "Dave Korn" <[EMAIL PROTECTED]> wrote:
> In fact, doesn't this suggest that in _most_ circumstances, *saturation*
> would be the best behaviour?
If that's for user-introduced overflows, it could be useful in some
cases, but I wouldn't go as far as `most'.
For compiler-introduc
On Jun 29, 2005, Olivier Galibert <[EMAIL PROTECTED]> wrote:
> char x = (char)((unsigned char)y + (unsigned char)z)
> is too ugly to live.
Yeah, indeed, one shouldn't assume char is signed :-) :-)
(strictly speaking, you don't, but I thought this would be funny so I
went ahead and posted it)
On Wed, Jun 29, 2005 at 02:12:40PM +0100, Dave Korn wrote:
> In fact, doesn't this suggest that in _most_ circumstances, *saturation*
> would be the best behaviour?
No, you'd be killing most emulators and a lot of virtual machine
implementations.
char x = (char)((unsigned char)y + (unsigned c
> Yes, I am pretty sure. I said "most lines of code", not "most
> applications",
> to indicate the density difference. If each line of code has, e.g., 1%
> chance
> to violate overflow rules, and 0.01% chance to violate aliasing rules,
> then for 10KLOC, you have:
> - probability of 63% to viola
Dave Korn wrote:
In fact, doesn't this suggest that in _most_ circumstances, *saturation*
would be the best behaviour?
Actually I think a handlable exception, a la Ada, is the best solution.
Whether saturation is appropriate is really problem dependent. If you
are counting the number of prim
Original Message
>From: Robert Dewar
>Sent: 29 June 2005 13:14
> Theodore Papadopoulo wrote:
>
>> So unless you do arithmetics or combinatorics, most of the uses of
>> "wide" (ie > 32b) integral types semantically (ie in the programmer's
>> mind) assume that overflow does not happen in pr
Theodore Papadopoulo wrote:
So unless you do arithmetics or combinatorics, most of the uses of
"wide" (ie > 32b) integral types semantically (ie in the programmer's
mind) assume that overflow does not happen in practise in the program.
I think that's probably right. And in the context of this
Eric Botcazou <[EMAIL PROTECTED]> wrote on 29/06/2005 11:49:24:
> > This is unlike aliasing, when most lines of code out there,
> > did not break aliasing rules (even before they were
> > introduced).
>
> Are you sure? IIRC -fstrict-aliasing was once enabled at -O2 and then
> disabled to give
On Wed, 2005-06-29 at 11:32 +0300, Michael Veksler wrote:
> This is unlike aliasing, when most lines of code out there,
> did not break aliasing rules (even before they were
> introduced). Int overflow is violated by most lines of
> code I have seen (it is very uncommon to find code that
> asserts
Michael Veksler wrote:
This is right to some extent, and I referred to it in my original
mail. I claim that it is easier to write a code that checks these cases
after the overflow, rather than before. I also claim that checking
overflows (as implied by the standard) results in almost pure
unsign
Robert Dewar <[EMAIL PROTECTED]> wrote on 29/06/2005 11:42:07:
> Michael Veksler wrote:
>
> > If the programmer wants a robust application,
> > then casting to unsigned must be present for almost any
> > usage of int.
>
> If you have a variable in your program that is signed but must
> always
> This is unlike aliasing, when most lines of code out there,
> did not break aliasing rules (even before they were
> introduced).
Are you sure? IIRC -fstrict-aliasing was once enabled at -O2 and then
disabled to give people more time to fix their code.
--
Eric Botcazou
Michael Veksler wrote:
If the programmer wants a robust application,
then casting to unsigned must be present for almost any
usage of int.
If you have a variable in your program that is signed but must
always be in the range of int, then int is the appropriate
representation. If the pressure i
After reading many messages on the subject of overflow
of signed integral values, I am inclined to think that the
standard was wrong to say that int overflow is undefined.
Of course this definition improves performance, but at
what cost? At the cost of program stability?
If the programmer wan
14 matches
Mail list logo
