Re: signed is undefined and has been since 1992 (in GCC)

[Robert Dewar <dewar@adacore.com>]

Gabriel Dos Reis wrote:
> Robert Dewar <dewar@adacore.com> writes:
> 
> | Gabriel Dos Reis wrote:
> | 
> | > The strict aliasing rule by itself does not show it is not a high level
> | > assembly language.  There are chips out there where you cannot access
> | > data willy-nilly through random register types.
> | 
> | And there are chips for which signed arithmetic is not wrap around!
> 
> yes, but that is irrelevant,  the assumptin was made that
> one knows what the chip provides.  

And if the chip provides two consistent models of arithmetic, you cannot
deduce from the standard that one is preferred over the other (e.g. logical
vs arithmetic instructions on the IBM mainframe, or trapping vs non-trapping
arithmetic on the MIPS). I would actually think that the trapping arithmetic
on the MIPS is a much better model of signed int's in C (the language as
defined by the standard) [of course, given the claim that so few people know
C, and those who do not have expectations, you may well decide to meet those
expectations if it is free to do so).

A good analogy here is Fortran allocation. Everyone *knows* that Fortran
allocates storage statically, and many programs rely on this, but even
Fortran-66 went to great pains to NOT say this, and a stack based implementation
was entirely conforming. However, as Burroughs found out, a stack based
Fortran was not very useable.

As I said in an earlier message, the issue here is one of tradeoffs. You
always prefer defined behavior to undefined, and if you cannot have defined,
the equivalent of Ada bounded error is still a huge improvement over undefined.

If there were no tradeoff with efficiency, there is an argument for testing
for every undefined situation at run time and raising a signal when it
occurs with an appropriate message. THat's of course impractical. Failing
that, if there is a sort of expected behavior (e.g. everyone knows function
pointers are the same length as int pointers), then it is good to conform
to this expectation if it can be done cheaply (are trampolines cheap enough?
probably not).

In the case of overflow, everyone would agree on avoiding the undefined
behavior if it is cheap enough. If it is not cheap enough, then I think
most people would accept the undefined status.

How can you make an informed decision with no data in a case like this?
Answer you can't!