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

Joerg Arndt arndt at
Mon Jun 2 09:00:25 CEST 2008

Hi everybody,

* Vincent Lefevre <vincent at> [Jun 02. 2008 16:17]:
> 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.

Most code doesn't, yes.  But: are we using bit-count anywhere?  I
would have a hard time to code bit-count so that it works on all
allowed models.  It may not even be well-defined on all models!

Look into Knuth's new text on bit-fiddling, "Hacker delight", or
the first chapter of
There are strong assumptions about the model used.

> > 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)?

Would you expect to see such CPU?  Even if so, would there likely
be a GMP port?

> > - 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.

As soon as your code depends on internal byte ordering, it depends
on the exact ordering!  Cf. /usr/include/endian.h
#define __LITTLE_ENDIAN 1234
#define __BIG_ENDIAN    4321
#define __PDP_ENDIAN    3412

> > - two's complement,
> > - no exception on integer overflow,
> In general, that's not necessary.

Yes, but I dare to say that a lot of code will break if you
compile it on ones complement.  I guess almost all code that
for some reason is "bit-aware" will break.

> 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.

I could easily adapt e.g. my low-level code for that.  Still I'd have
to make own branches for, say, long=43-bit, long=27-bit etc.
I could create a branch that will work for all sizes, but it will be

> 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.


But I argue that using intptr_t etc. as suggested may be OK but will
NOT magically make everything work on just any model!

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

cheers,   jj

More information about the gmp-discuss mailing list