addresses and integers

[j0mbolar]

I've read in the standard that addresses
basically can't be interpreted as integers.
If they can, it is implementation defined
behavior. However, if they can't be viewed
as integers in any sense as far as portability
goes, what then, should one think of addresses
being composed of?

[Andrey Tarasevich]

j0mbolar wrote:

I've read in the standard that addresses
basically can't be interpreted as integers.
If they can, it is implementation defined
behavior. However, if they can't be viewed
as integers in any sense as far as portability
goes, what then, should one think of addresses
being composed of?

Nothing. You don't need to think about it at all. Especially if you are
talking about portability. There's no portable context in C language
that relies in any way in the internal representation of a pointer.

--
Best regards,
Andrey Tarasevich

[David R Tribble]

junky_fellow wrote:

why the conversion of a pointer type variable to integer invalid ?
what's the reason behing that ?
i always had in my mind that pointer variable contains some address,
which is some integer value ? and i can add/subtract after typecasting
the pointer variable to int.

Many old C compilers (some of which still exist) for 16-bit MS-DOS typically
had the habit of converting pointers, which were composed of a 16-bit base
segment address and a 16-bit byte offset within the segment, into 16-bit
ints by simply truncating the high-order segment; teh result was the 16-bit
offset within the segment. Converting such an int value back into a pointer
did not always work, since the compiler had to assume a base segment (usually
the current data segment DS), which was not necessarily correct (e.g.,
because the original pointer came from the stack segment SS or from the
FAR heap).

I seem to recall some old MS-DOS compilers converting pointers (composed of
16-bit base plus 16-bit offset) into 32-bit long ints by simply copying
the 16+16 bit address into the 32-bit int. Doing any kind of arithmetic
on the resulting integer value would then yield surprising results, since
incrementing the 16th bit shifted the address by 4, not 64K. It required
special macros (usually found in some system header file) to extract the
segment and offset portions and then other macros to put them back into
pointer form.

Ah, the joys of the Intel segmented architecture!

-drt

[Mabden]

"David R Tribble" <da***@tribble. com> wrote in message
news:f4******** *************** ***@posting.goo gle.com...

Ah, the joys of the Intel segmented architecture!

Dunno for certain, but can't we thank Microsoft for that? I don't think the
segment / offset was part of the Intel hardware, but an OS thing. I don't
recall having to go to new hardware when MS decided the flat memory model
was better...

--
Mabden

[James Kuyper]

ju**********@ya hoo.co.in (junky_fellow) wrote in message news:<8c******* *************** ****@posting.go ogle.com>...
....

why the conversion of a pointer type variable to integer invalid ?
It's not necessarily invalid. If, after #include <stdint.h>, you find
that INTPTR_MAX has been #defined, then you can safely convert a
pointer value to an intptr_t. The result of that conversion can itself
be converted back to the same pointer type, in which case it will
compare equal to the original pointer value.

The problem is that the only useful thing the standard guarantees
about that integer value is the reverse conversion. Each
implementation can do it's own thing, and there's absolutely nothing
else that portable code can count on.
what's the reason behing that ?
It's invalid, when INTPTR_MAX hasn't been #defined, because that means
that pointers on this platform are too big to be stored in any integer
type.

The reason the standard doesn't provide any more useful information
about the converted pointer's value, is that many different machines
provide many different and mutually incompatible ways of defining such
a conversion. The standard, rather than trying to list all the
possible ways, simply gives up and says "don't ask me!".
i always had in my mind that pointer variable contains some address,
which is some integer value ? and i can add/subtract after typecasting
the pointer variable to int.

That's a nice thing to believe, and it's true on many platforms. It's
not true on others. If you want your code to be portable, make sure
that it doesn't rely upon that assumption being true

[Brian Inglis]

On Tue, 31 Aug 2004 00:48:10 GMT in comp.std.c, "Mabden"
<mabden@sbc_glo bal.net> wrote:

"David R Tribble" <da***@tribble. com> wrote in message
news:f4******* *************** ****@posting.go ogle.com...

Ah, the joys of the Intel segmented architecture!

Dunno for certain, but can't we thank Microsoft for that? I don't think the
segment / offset was part of the Intel hardware, but an OS thing. I don't
recall having to go to new hardware when MS decided the flat memory model
was better...

Segment addresses didn't become segment selectors until 286 protected
mode came out; and the flat memory model wasn't available until the
386, when the OS got the choice of running in real, 286 or 386
protected mode (remember the different Windows versions for each),
with multi-megabyte selector sizes which allowed the OS to set the
same base address and length for all the selectors to allow a flat
address space (and virtual 86 mode for a process in protected mode).

--
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada

Br**********@CS i.com (Brian[dot]Inglis{at}Syste maticSW[dot]ab[dot]ca)
fake address use address above to reply

[junky_fellow]

ku****@wizard.n et (James Kuyper) wrote in message news:<8b******* *************** ****@posting.go ogle.com>...

j0******@engine er.com (j0mbolar) wrote in message news:<2d******* *************** ****@posting.go ogle.com>...

I've read in the standard that addresses
basically can't be interpreted as integers.
If they can, it is implementation defined
behavior. However, if they can't be viewed
as integers in any sense as far as portability
goes, what then, should one think of addresses
being composed of?

A pointer is represented by a string of bytes that could also be
interpreted as a number, but the standard contains no guarantees about
the relationship between that number and the memory location pointed
at. For instance, adding 1 to the number doesn't necessarily produce a
pointer to the position immediately after the position that the
original pointer pointed at. It might produce an invalid pointer, or a
pointer pointing at a completely different object. Also, two pointers
that contain different bit patterns might point at the same location.

The only portably useful thing to think about a pointer is that it
identifies the location of an object. In order to say something more
detailed, you have to restrict comments to particular implementations
of C.

do we get any advantage by having "no relation between the pointer
value(interpret ed as a number) and the memory location pointed at" ?
if not then, why making things more complex ?
why not represent the pointer as the integer address of the memory
location it is pointing to ?

[Douglas A. Gwyn]

junky_fellow wrote:

why the conversion of a pointer type variable to integer invalid ?
Why should it be valid? They're entirely different
kinds of thing, with different properties and uses.
i always had in my mind that pointer variable contains some address,
which is some integer value ? and i can add/subtract after typecasting
the pointer variable to int.

Not always, as has been explained by several recent
postings.

[Douglas A. Gwyn]

junky_fellow wrote:

do we get any advantage by having "no relation between the pointer
value(interpret ed as a number) and the memory location pointed at" ?
Yes. It allows the C implementation to present the
"address" encoding in the most atural manner for the
particular system. If the system does not have a
flat, byte-addressable data memory organization,
then pretending that it has one would involve
unnecessary complexity and serve no useful purpose.
why not represent the pointer as the integer address of the memory
location it is pointing to ?

There may be no such thing!

[Brian Inglis]

On 30 Aug 2004 22:25:14 -0700 in comp.std.c, ju**********@ya hoo.co.in
(junky_fellow) wrote:

ku****@wizard. net (James Kuyper) wrote in message news:<8b******* *************** ****@posting.go ogle.com>...

j0******@engine er.com (j0mbolar) wrote in message news:<2d******* *************** ****@posting.go ogle.com>...

> I've read in the standard that addresses
> basically can't be interpreted as integers.
> If they can, it is implementation defined
> behavior. However, if they can't be viewed
> as integers in any sense as far as portability
> goes, what then, should one think of addresses
> being composed of?
A pointer is represented by a string of bytes that could also be
interpreted as a number, but the standard contains no guarantees about
the relationship between that number and the memory location pointed
at. For instance, adding 1 to the number doesn't necessarily produce a
pointer to the position immediately after the position that the
original pointer pointed at. It might produce an invalid pointer, or a
pointer pointing at a completely different object. Also, two pointers
that contain different bit patterns might point at the same location.

The only portably useful thing to think about a pointer is that it
identifies the location of an object. In order to say something more
detailed, you have to restrict comments to particular implementations
of C.

do we get any advantage by having "no relation between the pointer
value(interpre ted as a number) and the memory location pointed at" ?

There is a relation, but it's not always the obvious, expected one;
sometimes its just the hardware, and sometimes the compiler has to
help out inadequate hardware.
if not then, why making things more complex ?
Compilers don't make things any more complex than the hardware and
language require, and the language often doesn't require anything more
than documenting strange behaviour.
why not represent the pointer as the integer address of the memory
location it is pointing to ?

That's not always how the hardware works, and even if it is, it may
not directly support all the language requirements (read as:
programmer expectations), and may need some compiler help.

--
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada

Br**********@CS i.com (Brian[dot]Inglis{at}Syste maticSW[dot]ab[dot]ca)
fake address use address above to reply

[Dan Pop]

In <8b************ **************@ posting.google. com> ku****@wizard.n et (James Kuyper) writes:

ju**********@y ahoo.co.in (junky_fellow) wrote in message news:<8c******* *************** ****@posting.go ogle.com>...
...

why the conversion of a pointer type variable to integer invalid ?

It's not necessarily invalid. If, after #include <stdint.h>, you find
that INTPTR_MAX has been #defined, then you can safely convert a
pointer value to an intptr_t. The result of that conversion can itself
be converted back to the same pointer type, in which case it will
compare equal to the original pointer value.

The problem is that the only useful thing the standard guarantees
about that integer value is the reverse conversion. Each
implementati on can do it's own thing, and there's absolutely nothing
else that portable code can count on.

what's the reason behing that ?

It's invalid, when INTPTR_MAX hasn't been #defined, because that means
that pointers on this platform are too big to be stored in any integer
type.

Can I have a chapter and verse for that?

The implementor is free not to provide [u]intptr_t and the associated
macros, regardless of how the conversion between pointers and integers
works. It's a quality of implementation issue and the lack of INTPTR_MAX
doesn't mean that (uintmax_t)ptr necessarily invokes undefined behaviour
or yields a meaningless result.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de