Re: different compilers: different standard types?????

[Stephen Leake <stephen_leake@acm.org>]

Marius Amado Alves <maa@liacc.up.pt> writes:

> The standard requires that "the range of Integer should be no wider
> than that of Long_Integer" 3.5.4 (25). (I'm not sure this is an
> intelligent limitation, but never mind.) 

What would you like it to say instead?

> GNAT defines Integer and Long_Integer for 32-bit, and
> Long_Long_Integer for 64-bit.
> 
> So if you want to define an integral type with a greater range than
> (the associated with) 32 bits, you have to use Long_Long_Integer as
> a base. 

Hmm. Let's declare a type:

type My_Long_Int is range -2**50 .. 2**50 -1;

You don't _specify_ Long_Long_Integer, but the compiler does use a 64
bit integer as the base type. Just to be picky :).

> But then you hinder portability, because Long_Long_Integer is not
> standard.

The problem is not that Long_Long_Integer is not standard; the problem
is that 64 bits is not standard. Neither, for that matter, is 32 bits;
the standard only requires 16 bit integers.

> So I guess my question is: Why does not GNAT define Integer (and
> Long_Integer) for 64-bits? 

How would that improve portability? As long as other compilers don't
support 64 bit integers, using them will be none-portable.

Integer is used for the index of String; it probably does not make
sense for that to be 64 bits. Why waste space?

It might make sense for Long_Integer to be 64 bits. 

But none of this really matters; you should _never_ use an integer
type declared in Standard (except Integer for String indices, or when
you really don't care about size).

> AFAICS the standard does not impose a upper limit on Integer.

True.

> And don't tell me the answer is: Because then Short_Integer would
> have 32-bits, and that is not what the C world calls short.

That is certainly not the answer; C types are in Interfaces.C, not
Standard.

-- 
-- Stephe