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
13 matches
Mail list logo
