Re: Ada Pointer Size Problem

[Dave Thompson <david.thompson1@worldnet.att.net>]

On Thu, 21 Oct 2004 01:56:28 GMT, Jeffrey Carter <spam@spam.com>
wrote:

> Dave Thompson wrote:
> 
> > On Mon, 11 Oct 2004 05:18:58 GMT, Jeffrey Carter <spam@spam.com> 
> > wrote:
> >> 
> >> In C/++, a pointer is an int is an address. In Ada, they're 3
> >> different things.
> > 
> > But (unlike its predecessor B) a C pointer/address is not just an
> > int.
> 
> I meant that a pointer is an int because you can always convert/assign a
> pointer to an int.

Well, in many languages (not just C) you can just assign an integer
(or fixed-point) value to floating-point and vice versa, but I sure
wouldn't say that either "is" the other.

And you can't assign C pointer to integer without conversion; it
violates a constraint. (Or pass as parameter or return as value, since
in C those are always semantically equivalent to assignment.)

You can write the conversion to any integer type explicitly with a
cast, but the result is implementation-defined and may or may not be
useful. For most mainstream systems there is a simple and useful
mapping and that is what any sensible implementation provides, but the
Standard doesn't require it. 

As others have already said, the specific type 'int', which is only
one of the integer types provided by a conforming C, need not be large
enough to handle (all) addresses. In addition to the 286 example, I
have long personal experience of the "classic" (that is, pre-RISC,
still used in emulation) Tandem^WCompaq^WHP NonStop, with three
execution models: IP16, I16P32, and IP32; corresponding basically to
different stages in their CPU/ISA evolution. In the "large" I16P32
model obviously pointer in int doesn't work.

The new-in-C99 names intptr_t and uintptr_t are integer types
guaranteed large enough to losslessly store (with the explicit
conversion) any (data) pointer, but are optional; an implementation
need not provide them if it doesn't have a suitable integer type. As
with all the new <stdint.h> types, there is an associated preprocessor
macro you can test to determine if the type is present, and thus write
code that works-around the omission or at least fails gracefully --
but only with the ugliness typical of preprocessor solutions, as often
discussed here. But machines that actually can't do address arithmetic
-- and thus reasonably support such an integer type -- are for obvious
reasons pretty damn rare if they exist at all, and also (would be)
very unlikely to be able to support the rest of C anyway.

- David.Thompson1 at worldnet.att.net