Ada Pointer Size Problem

Ada Pointer Size Problem

[skidmarks]

I have a problem with the test program below. Perhaps someone can help me.

1. P1_Size gives an error. P2_Size and P3_Size don't. 
   I would have expected errors everywhere or nowhere.
   I don't understand what is 'non-static' about the
   expression since a typedef is invariant.

2. 'thang' (L13) is erroneous but 'Variable' (L17) is
   not. I suspect that this means that the non-static
   nature of the expression is OK as a statement but
   not in a definition.

3. The string pointer size (eliding the error statements)
   is 64-bits. I am using an AMD 2100 (32-bit) computer
   and gcc-3.3.3-3. I would have expected a 32-bit
   pointer. 

4. The integer pointer size (eliding the error statements)
   is 32-bits. I would have expected that it would be the
   same size as the string pointer.

I've looked at the 'info' tex file included with the 
gcc distribution and so far have not found how to 
change a 64-bit pointer to a 32-bit pointer. I've
thought that maybe I am getting the dope vector size
associated with the String_Ptr but this really doesn't
make sense. The Integer_Ptr is only 32-bits which 
seems to be correct but both pointers should be the 
same.

Any idea of what I'm really missing?

art


--------------------------------------------------------

# compiling under Cygwin on a Windows 2000, AMD 2100 CPU
#  gcc-3.3.3-3

>> gcc -c -gnatfv -gnatl junk.adb

GNAT 3.3.3 (cygwin special)
Copyright 1992-2002 Free Software Foundation, Inc.

Compiling: junk.adb (source file time stamp: 2004-10-10 19:50:18)

     1. with Text_IO; use Text_IO;
     2.
     3. procedure junk is
     4.    type String_Ptr  is access all String;
     5.    type Integer_Ptr is access all Integer;
     6.
     7.    In_Size  : constant         := Integer'Size;
     8.    Fl_Size  : constant         := Float'Size;
     9.    P1_Size  : constant         := String_Ptr'Size;
                                                    |
        >>> non-static expression used in number declaration

    10.    P2_Size  : Integer          := String_Ptr'Size;
    11.    P3_Size  : constant Integer := String_Ptr'Size;
    12.    thing    : constant         := Integer'Max(In_Size, Fl_Size);
    13.    thang    : constant         := Integer'Max(thing, P2_Size);
                                                 |
        >>> non-static expression used in number declaration

    14.    Variable : Integer;
    15.
    16. begin -- junk
    17.    Variable         := Integer'Max(In_size, String_Ptr'Size);
    18.    Put_Line("Integer = " & Integer'Image(Integer'Size) );     -- 32 bits
    19.    Put_Line("Float   = " & Integer'Image(Float'Size)   );     -- 32 bits
    20.    Put_Line("Int_Ptr = " & Integer'Image(Integer_Ptr'Size));  -- 32 bits
    21.    Put_Line("Ptr     = " & Integer'Image(String_Ptr'Size));   -- 64 bits
    22.    Put_Line("Ptr1    = " & Integer'Image(P1_Size));           -- 64 bits
    23.    Put_Line("Ptr2    = " & Integer'Image(P2_Size));           -- 64 bits
    24.    Put_Line("Ptr3    = " & Integer'Image(P3_Size));           -- 64 bits
    25.    Put_Line("Variable= " & Integer'Image(Variable));          -- 64 bits
    26. end junk;

 26 lines: 2 errors
>>

Re: Ada Pointer Size Problem

[Stephen Leake]

aschwarz@acm.org (skidmarks) writes:

> I have a problem with the test program below. Perhaps someone can help me.
> 
> 1. P1_Size gives an error. P2_Size and P3_Size don't. 
>    I would have expected errors everywhere or nowhere.
>    I don't understand what is 'non-static' about the
>    expression since a typedef is invariant.

Gnat 5.02a1 says:

junk.adb:9:35: non-static expression used in number declaration
junk.adb:9:45: size attribute is only static for scalar type (RM 4.9(7,8))
junk.adb:13:35: non-static expression used in number declaration
junk.adb:13:54: "P2_Size" is not static constant or named number (RM 4.9(5))

In general 'static' means "known at compile time", but the details in
the RM sometimes deviate from that simple description. The reasons
have to do with making the compiler easier to right, mostly. I think
Ada 2005 will be making more things static.

> 3. The string pointer size (eliding the error statements)
>    is 64-bits. I am using an AMD 2100 (32-bit) computer
>    and gcc-3.3.3-3. I would have expected a 32-bit
>    pointer. 

Just shows the compiler knows better than you do :).

A pointer to an unconstrained array also needs a 'dope vector', that
stores the bounds of the array.

> 4. The integer pointer size (eliding the error statements)
>    is 32-bits. I would have expected that it would be the
>    same size as the string pointer.
> 
> I've looked at the 'info' tex file included with the 
> gcc distribution and so far have not found how to 
> change a 64-bit pointer to a 32-bit pointer. 

Why do you want to do that? A pointer to an integer is not a pointer
to a string.

> I've thought that maybe I am getting the dope vector size associated
> with the String_Ptr but this really doesn't make sense. 

Why doesn't that make sense?

> The Integer_Ptr is only 32-bits which seems to be correct but both
> pointers should be the same.

Why?

-- 
-- Stephe

Re: Ada Pointer Size Problem

[Jeffrey Carter]

skidmarks wrote:
> 3. The string pointer size (eliding the error statements)
>    is 64-bits. I am using an AMD 2100 (32-bit) computer
>    and gcc-3.3.3-3. I would have expected a 32-bit
>    pointer. 

The first question, as always, is why you're using access types, and why 
you care how the compiler represents them. As an apparent beginner in 
Ada, you should not need access types, unless you're doing an assignment 
on dynamic data structures.

String_Ptr isn't a pointer; it's an access type. As pointed out in 
another thread, access values are not necessarily pointers, and that's 
why they're not called pointers. In this case, the extra space is 
probably connected to the bounds information needed for the array.

> Any idea of what I'm really missing?

Probably the difference between pointers in simple languages and access 
values in high-level languages. In C/++, a pointer is an int is an 
address. In Ada, they're 3 different things.

-- 
Jeff Carter
"Don't knock masturbation. It's sex with someone I love."
Annie Hall
45

Re: Ada Pointer Size Problem

[Martin Krischik]

skidmarks wrote:

> I have a problem with the test program below. Perhaps someone can help me.

Well an access is not a pointer. System.Address is a pointer.  There are
functions to convert an access to an Address..An access may contain
additional informations apart from the pointer - like size of the object
pointed to (for indefinite objects), a reference counter (for access all or
anonymous access) etc. pp. 

> I've looked at the 'info' tex file included with the 
> gcc distribution and so far have not found how to 
> change a 64-bit pointer to a 32-bit pointer

The System package has the needed convetion functions.

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Ada Pointer Size Problem

[skidmarks]

Stephen Leake <stephen_leake@acm.org> wrote in message news:<mailman.269.1097458704.390.comp.lang.ada@ada-france.org>...
> aschwarz@acm.org (skidmarks) writes:

> > I've looked at the 'info' tex file included with the 
> > gcc distribution and so far have not found how to 
> > change a 64-bit pointer to a 32-bit pointer. 
> 
> Why do you want to do that? A pointer to an integer is not a pointer
> to a string.

  I misspoke, perhaps sarcastically. I don't want to change pointer sizes
  and you have gone far to explain what I'm seeing. Although the reason
  for including the dope vector as part of an Access Type eludes me, the
  explanation I understand. (The elusion is because it seems just as
  reasonable to 'point' to a dope vector when specifying an access type
  rather than including the dope vector as the Access Type.) Albeit, 
  thanks to all for the clarification between System.Address and Access
  Type.

> 
> > I've thought that maybe I am getting the dope vector size associated
> > with the String_Ptr but this really doesn't make sense. 
> 

  See above. To resolve this (type of) difficulty locally - for Ada83
  interfaces to C primarily, we do the following:

   A_Access   := array'Access
   B_Pointer  := array(array'First)'Address

  and for the purists, THIS IS NOT TRUE ADA, so don't flame me because
  it's not true Ada.

> Why doesn't that make sense?
> 
> > The Integer_Ptr is only 32-bits which seems to be correct but both
> > pointers should be the same.
> 
> Why?

  See above.

And to all, thanks. You have clarified the issues.

art

Re: Ada Pointer Size Problem

[Jeffrey Carter]

skidmarks wrote:
> 
>    A_Access   := array'Access
>    B_Pointer  := array(array'First)'Address

I realize this is conceptual, not code, but this is not Ada-83 like. In 
Ada 95, you can declare an access type to have convention C:

type Str_Ptr is access all String;
pragma Convention (C, Str_Ptr);

Str_Ptr will be a pointer in the C sense. In Ada 83, System.Address and 
'Address is usually appropriate.

-- 
Jeff Carter
"My legs are gray, my ears are gnarled, my eyes are old and bent."
Monty Python's Life of Brian
81

Re: Ada Pointer Size Problem

[Martin Krischik]

skidmarks wrote:

> Stephen Leake <stephen_leake@acm.org> wrote in message
> news:<mailman.269.1097458704.390.comp.lang.ada@ada-france.org>...
>> aschwarz@acm.org (skidmarks) writes:
> 
>> > I've looked at the 'info' tex file included with the
>> > gcc distribution and so far have not found how to
>> > change a 64-bit pointer to a 32-bit pointer.
>> 
>> Why do you want to do that? A pointer to an integer is not a pointer
>> to a string.
> 
>   I misspoke, perhaps sarcastically. I don't want to change pointer sizes
>   and you have gone far to explain what I'm seeing. Although the reason
>   for including the dope vector as part of an Access Type eludes me, the
>   explanation I understand. (The elusion is because it seems just as
>   reasonable to 'point' to a dope vector when specifying an access type
>   rather than including the dope vector as the Access Type.) Albeit,
>   thanks to all for the clarification between System.Address and Access
>   Type.

Actually the compiler vendors are free to choose the implementation thats
suits them best.

>> > I've thought that maybe I am getting the dope vector size associated
>> > with the String_Ptr but this really doesn't make sense.
>> 
> 
>   See above. To resolve this (type of) difficulty locally - for Ada83
>   interfaces to C primarily, we do the following:
> 
>    A_Access   := array'Access
>    B_Pointer  := array(array'First)'Address
> 
>   and for the purists, THIS IS NOT TRUE ADA, so don't flame me because
>   it's not true Ada.

I use this trick as well from time to time in Ada 95. It's faster and saves
memory. 

Even cooler:

type Ada_String is String (1.. C_String_Len);
for Ada_String'Address use C_String'Address;

With Regads

Martin
-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Ada Pointer Size Problem

[Dmitry A. Kazakov]

On 13 Oct 2004 06:05:59 -0700, Hans Van den Eynden wrote:

> Martin Krischik <krischik@users.sourceforge.net> wrote in message news:<1404015.dag8674995@linux1.krischik.com>...
>> skidmarks wrote:
>> 
>>> I have a problem with the test program below. Perhaps someone can help me.
>> 
>> Well an access is not a pointer. System.Address is a pointer.  There are
>> functions to convert an access to an Address..An access may contain
>> additional informations apart from the pointer - like size of the object
>> pointed to (for indefinite objects), a reference counter (for access all or
>> anonymous access) etc. pp. 
>> 
>>> I've looked at the 'info' tex file included with the 
>>> gcc distribution and so far have not found how to 
>>> change a 64-bit pointer to a 32-bit pointer
>> 
>> The System package has the needed convetion functions.
>> 
>> With Regards
>> 
>> Martin
> 
>> There are functions to convert an access to an Address
>  
> Are there also functions that convert an Address to an access?? And
> what about Ada's type safety than ??

The reset button is always at your service, then! (:-))

> I also can't anything about System.Address in the Ada95RM, a leftover
> from Ada83?

See ARM 13.7.2

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada Pointer Size Problem

[Jean-Pierre Rosen]

skidmarks a écrit :


>   I misspoke, perhaps sarcastically. I don't want to change pointer sizes
>   and you have gone far to explain what I'm seeing. Although the reason
>   for including the dope vector as part of an Access Type eludes me, the
>   explanation I understand. (The elusion is because it seems just as
>   reasonable to 'point' to a dope vector when specifying an access type
>   rather than including the dope vector as the Access Type.) 
It is not always possible to have the dope just before the array.
For example, you can point to a slice of a string...
-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Ada Pointer Size Problem

[Steve]

The package "System.Address_To_Access_Conversions" is what you're looking
for.

http://www.adaic.org/standards/95lrm/html/RM-13-7-2.html

Steve
(The Duck)

"Hans Van den Eynden" <onsbomma@hotmail.com> wrote in message
news:1c2f5137.0410130505.57e03c@posting.google.com...
>[snip]
>
> > There are functions to convert an access to an Address
>
> Are there also functions that convert an Address to an access?? And
> what about Ada's type safety than ??
> I also can't anything about System.Address in the Ada95RM, a leftover
> from Ada83?

Re: Ada Pointer Size Problem

[Dave Thompson]

On Mon, 11 Oct 2004 05:18:58 GMT, Jeffrey Carter <spam@spam.com>
wrote:

> skidmarks wrote:
<snip: access types versus addresses>
> > Any idea of what I'm really missing?
> 
> Probably the difference between pointers in simple languages and access 
> values in high-level languages. In C/++, a pointer is an int is an 
> address. In Ada, they're 3 different things.

This is overstating the case.

In C a pointer value is in practice just an address. This isn't
formally required, but traditionally it's so; the standard specifies
(intentionally) semantics that allow it; and anything else is
unacceptably (to most users) inefficient, since C requires many array
accesses -- thus including character strings -- to go through
pointers, and all pointers of a given type to be the same -- unlike
non-all access or PL/I OFFSET.

But (unlike its predecessor B) a C pointer/address is not just an int.
It has addition and subtraction, but scaled by the target size
(stride) -- and standardly only required to work within a single
variables; there is not required to be a flat address space, although
that is common and some C program/mers unportably rely on it. Other
operations which would be meaningless like multiply and divide are
prevented, and conversions are explicit, like System.Address.

In C++ the same is true for builtin/standard pointers, but the
standard library provides a number of enhanced pointer-like types that
can be used transparently, and you (or someone) can write your own.

- David.Thompson1 at worldnet.att.net

Re: Ada Pointer Size Problem

[Jeffrey Carter]

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.

-- 
Jeff Carter
"Ada has made you lazy and careless. You can write programs in C that
are just as safe by the simple application of super-human diligence."
E. Robert Tisdale
72

Re: Ada Pointer Size Problem

[Martin Krischik]

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

Not on a 64 bit CPU. Most 64bit compiler have not expanded int to 64 bit (as
they should have done). Only "intptr_t" and "uintptr_t" are large enough to
store a pointer.

If you use MS-C then activate /W64 and see what happens. 

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Ada Pointer Size Problem

[Jeffrey Carter]

Martin Krischik wrote:

> If you use MS-C then activate /W64 and see what happens. 

I don't use C, and am speaking from several-year-old memory. Every C 
I've ever used allowed a pointer or address to be stored in an int.

-- 
Jeff Carter
"You cheesy lot of second-hand electric donkey-bottom biters."
Monty Python & the Holy Grail
14

Re: Ada Pointer Size Problem

[Simon Wright]

Jeffrey Carter <spam@spam.com> writes:

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

I'm pretty sure that on Alphas (this was OSF/1 unix) a pointer was a
long (64 bits) while an int was 32 bits .. so, assign away, just don't
expect things to work portably for ever!

-- 
Simon Wright                               100% Ada, no bugs.

Re: Ada Pointer Size Problem

[Martin Krischik]

Jeffrey Carter wrote:

> Martin Krischik wrote:
> 
>> If you use MS-C then activate /W64 and see what happens.
> 
> I don't use C, and am speaking from several-year-old memory.

Well, /W64 works for MS-C++ as well.

> Every C 
> I've ever used allowed a pointer or address to be stored in an int.

Then you have used C only in a very small windows of opportunity. You have
missed the intersting world of the 80286 with it's host of very interesting
memory models.

And you have not yet arrived the great new world of 64 bit computing - where
a pointer is twice the size of an int.

With Regards

Martin
-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Ada Pointer Size Problem

[Adrien Plisson]

Martin Krischik wrote:
> Jeffrey Carter wrote:
>>Every C 
>>I've ever used allowed a pointer or address to be stored in an int.
> 
> Then you have used C only in a very small windows of opportunity. You have
> missed the intersting world of the 80286 with it's host of very interesting
> memory models.

in C and C++ on most 32 bits platforms:
sizeof( void *) == sizeof( long ) == sizeof( int ) == 4
that's why he is allowed to store pointers in an int. to use 64 bit wide 
integers, you have to use __int64.

so I don't think he missed the 80286 and its bunch of wonderful memory 
models...

> And you have not yet arrived the great new world of 64 bit computing - where
> a pointer is twice the size of an int.

well, we have to get prepared for the future world of 128 bit computing.
coming sooner or later to a computer near you !

-- 
rien

Re: Ada Pointer Size Problem

[Warren W. Gay VE3WWG]

Adrien Plisson wrote:

> Martin Krischik wrote:
>> Jeffrey Carter wrote:
>>> Every C I've ever used allowed a pointer or address to be stored in 
>>> an int.
>>
>> Then you have used C only in a very small windows of opportunity. You 
>> have
>> missed the intersting world of the 80286 with it's host of very 
>> interesting
>> memory models.
> 
> in C and C++ on most 32 bits platforms:
> sizeof( void *) == sizeof( long ) == sizeof( int ) == 4
> that's why he is allowed to store pointers in an int. to use 64 bit wide 
> integers, you have to use __int64.
...
> well, we have to get prepared for the future world of 128 bit computing.
> coming sooner or later to a computer near you !

This brings up an interesting point WRT Ada: since much C/C++
code has depended upon this relationship and Ada does not (though
it can be abused). Ada code in this respect at least, should more
easily adapt to platforms with increasing sizes of address spaces.
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Ada Pointer Size Problem

[Mark Lorenzen]

Jeffrey Carter <spam@spam.com> writes:

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

You can do that in Ada also. See ARM 3.7.1.(10) and 3.7.1.(13). This
does of course not mean that a value of type Address is an integer
subtype.

- Mark Lorenzen

Re: Ada Pointer Size Problem

[Jeffrey Carter]

Martin Krischik wrote:

> Well, /W64 works for MS-C++ as well.

I don't use C-incremented, either.

> Then you have used C only in a very small windows of opportunity. You
> have missed the intersting world of the 80286 with it's host of very
> interesting memory models.

I have indeed avoided using C on most platforms.

> And you have not yet arrived the great new world of 64 bit computing
> - where a pointer is twice the size of an int.

Actually, I started my career in professional software development in 
the world of 60-bit computing, with 120-bit double-precision 
floating-point values. Most processors since then have seemed sort of 
like a step backwards. However, they cost a lot less and didn't take up 
most of 2 floors at the university computer center.

-- 
Jeff Carter
"You couldn't catch clap in a brothel, silly English K...niggets."
Monty Python & the Holy Grail
19

Re: Ada Pointer Size Problem

[Martin Krischik]

Jeffrey Carter wrote:

> Martin Krischik wrote:
> 
>> Well, /W64 works for MS-C++ as well.
> 
> I don't use C-incremented, either.

After more the 10 years of C++ I do envy you.

>> Then you have used C only in a very small windows of opportunity. You
>> have missed the intersting world of the 80286 with it's host of very
>> interesting memory models.
> 
> I have indeed avoided using C on most platforms.

You are a very lucky man that you could make that decision.

>> And you have not yet arrived the great new world of 64 bit computing
>> - where a pointer is twice the size of an int.
> 
> Actually, I started my career in professional software development in
> the world of 60-bit computing, with 120-bit double-precision
> floating-point values. Most processors since then have seemed sort of
> like a step backwards. However, they cost a lot less and didn't take up
> most of 2 floors at the university computer center.

<grin>

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Ada Pointer Size Problem

[Martin Krischik]

Adrien Plisson wrote:

> Martin Krischik wrote:
>> Jeffrey Carter wrote:
>>>Every C
>>>I've ever used allowed a pointer or address to be stored in an int.
>> 
>> Then you have used C only in a very small windows of opportunity. You
>> have missed the intersting world of the 80286 with it's host of very
>> interesting memory models.
> 
> in C and C++ on most 32 bits platforms:
> sizeof( void *) == sizeof( long ) == sizeof( int ) == 4
> that's why he is allowed to store pointers in an int. to use 64 bit wide
> integers, you have to use __int64.

Only the the computers I bought recently are 64 bit and - if you belive in
Moors law - transition to greater 2 GB of main memory for general use
should happen within the next 18 month.

BTW: You should store pointers in intptr_t or uintptr_t.

And you should not use datatypes which start with two "_" - If you need 64
bits you should use int64_t.

> so I don't think he missed the 80286 and its bunch of wonderful memory
> models...

There was a bit of sarcasm on my side here.

>> And you have not yet arrived the great new world of 64 bit computing -
>> where a pointer is twice the size of an int.
> 
> well, we have to get prepared for the future world of 128 bit computing.
> coming sooner or later to a computer near you !

Well Moors law demands an additional bit ever 18 month. So PC's will need
128 bit address space in about 24 years. Workstations, Server etc. pp. a
little sooner.

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Ada Pointer Size Problem

[Dave Thompson]

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