GMP and 64-bit systems

Joerg Arndt arndt at
Sun Jun 1 18:40:16 CEST 2008

Hello anonymous,

* NightStrike <nightstrike at> [Jun 02. 2008 01:55]:
> On 6/1/08, Joerg Arndt <arndt at> wrote:
> > * librik at <librik at> [Jun 01. 2008 18:25]:
> > > A conclusion:  any integer type intended to be 32 bits on 32-bit
> > > systems and 64 bits on 64-bit systems cannot be a basic C type.  It
> > > must be a typedef type, whose identity is controlled by an #ifdef in
> > > some header file.
> >
> > Yes that's the price for the full adherence to the standard.  I
> > suggest sticking to LP64 (and saying so in the doc!), and, when it's
> > not there, bailing out with an error (or warning).
> > Or falling back to a safe but potentially slow code branch.
> So you don't want to support Win64 at all?  Oh, how delightful...

As I did write earlier I will not personally contribute code
for the Windows O/S.  You are free to do so if you like.

> If you don't understand *why* Microsoft went with the model they
> chose, then maybe you should take a few minutes to learn.  They have
> published several informative documents on msdn which explain -- in
> great detail -- why they went with int=long=32.

I have not seen those documents.
A URL would be helpful indeed.

>  Before you just make
> blanket statements (and repeat yourself 5 times with the same blanket
> statement) that a model is not "sane", you would do well to know a bit
> more about what you are evaluating.
> It was said perfectly well earlier in this thread -- if you assume
> that you can freely cast between pointers and longs, you are a bad C
> programmer and you are writing bad C code.  End of story.

It should be perfectly clear from my earlier mails that I do not
assume any such thing.

> Use size_t for unsigned, ssize_t for signed, and intptr_t for any data
> structure that is storing a pointer.  Why is that so difficult?

Did I say it is?  No.

Does the standard guarantee that intptr_t is OK for all types of pointers?
I tried to find the spot, but couldn't right now.

More information about the gmp-discuss mailing list