Could we agree to disagree and come together on improvements andclean-up?

[Vincent Lefevre]

On 2008-06-01 21:02:08 +1000, Joerg Arndt wrote:
> However, taking care of everything allowed by the standard is IMHO
> unwise.  For one example, ones complement, I'd be surprised if more
> than 1 percent of all existing code would do what it's meant to do
> when compiled on a ones-complement environment.

I agree for one's complement, but I'd say that most code doesn't need
to assume two's complement.

> Roughly, the code should work on what I call a sane arch/model:
> - long is machine word,

No, long should just fit the needs. What if a processor has 32-bit
words and use pointers on 64 bits (two words)?

> - byte order is little- or big- endian (not 1342 or such),

In general, if one supports both little- and big-endian, one doesn't
need to assume more.

> - two's complement,
> - no exception on integer overflow,

In general, that's not necessary. Not assuming wrapping is sufficient,
and also *necessary* in practice because of optimizations (now you can
still write code for gcc and use -fwrap if you want to assume wrapping).

> - bits per int/long is a power of two

On some platforms, this isn't the case, for good reasons. And it isn't
necessary assume a power of two. C99 already provides types that offer
this guarantee.

BTW, you forgot GPUs that don't even have a conventional processing
model. And it is much harder to write code for GPUs than for machines
with one's complement, mixed-endian and so on.

-- 
Vincent Lefèvre <vincent at vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)