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 be in the range of int, then int is the appropriate
> representation. If the pressure in a tank must be in the
> range -2**31 .. +2**31-1, it does not make the application
> more robust to ensure that if the pressure goes "over" the max, it
> suddenly turns negative. That's likely to be just as
> disastrous as any other behavior in this serious error
> situation.

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
unsigned arithmetic, so why do we have signed arithmetic
to begin with?

>
> In practice of course, the pressure in this example is
> likely to be in a much more constrained range, and part
> of making a "robust application" will be to ensure that
> the value always remains in the required range. In a more
> expressive language like Ada, the corresponding type would
> be declared with the appropriate range, and an exception
> would be raised if the value is outside this range.

But this is not what C does. In C there is an assumption
"bugs like int overflow may be transformed into any other
possible bug". No exception need be raised.

> In practice in a critical application, you are likely to
> not want any exceptions, so proving such a program exception
> free is one of the tasks that faces the applications programmer
> in writing a reliable program. See for example:
>
> http://www.praxis-cs.com/pdfs/Industrial_strength.pdf
>

And as it is written in section 3
"... gives compiler writers substantial freedom to re-order expressions
..."
and then
"A more sound approach is to design a language so that these
ordering effects cannot occur".
This last quote can be implemented only by moving to modulo semantics.




Reply via email to