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?

[pete]

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?

Bases and offsets.

--
pete

[Jack Klein]

On Mon, 30 Aug 2004 00:21:31 GMT, pete <pf*****@mindsp ring.com> wrote
in comp.lang.c:

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?

Bases and offsets.

Can you provide any justification at all for your apparently
ridiculous assertion?

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.l earn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Jack Klein]

On 29 Aug 2004 16:57:46 -0700, j0******@engine er.com (j0mbolar) wrote
in comp.lang.c:

I've read in the standard that addresses
basically can't be interpreted as integers.
That's right, addresses are constants. In fact, they are rvalues, not
lvalues. Functions can't be interpreted as integers either, nor can
structures. What of it?
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?

Addresses in C are not "composed" of anything. They have no defined
inner structure, just as the floating point types do not.

There is a requirement that an address can be represented in a string
of binary digits, because an address can be stored in a pointer object
of appropriate type, that pointer object can be inspected as an array
of unsigned chars, and upon such inspection the pointer object must
contain bits and nothing but bits.

This same possibility of inspection as the bits contained in an array
of unsigned characters also applies to the floating point types, but
the interpretation or meaning of those bits is totally unspecified by
the standard.

The standard does require that if an implementation provides an
integer type wide enough to contain a pointer, assignment with a cast
of a pointer value to that integer type and back again with a cast to
the original pointer type will yield an identical pointer. C99 even
defines typedef to be used for such a type, intptr_t and uintptr_t,
although they are optional. I think it would have been preferable for
the standard require the typedefs if such an integer type existed, the
way it requires the exact width definitions.

The standard does not require or guarantee that you can do anything
useful with a converted pointer in such a type, other than converting
it back. In particular, there is no guarantee that:

char name [] = "name";
char *n = name;
uintptr_t up = n;
++up;
n = up;

....n now points to the 'a' in name, or has any valid value at all.

Addresses have absolutely no portability at all, even between
executions of the same program.

What portability do you think they should have, and why? And why do
you think you need to think of them or treat them as integers? What
is it that you think you need to do with addresses that cannot
legitimately be done with pointers?

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.l earn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.l earn.c-c++ http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Barry Margolin]

In article <nr************ *************** *****@4ax.com>,
Jack Klein <ja*******@spam cop.net> wrote:

On Mon, 30 Aug 2004 00:21:31 GMT, pete <pf*****@mindsp ring.com> wrote
in comp.lang.c:

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?

Bases and offsets.

Can you provide any justification at all for your apparently
ridiculous assertion?

That's how C pointers were implemented on Symbolics Lisp Machines.
That's also a non-ridiculous way to implement them on a CPU that has a
reasonable segmented architecture (as opposed to the hoops you have to
jump through to use x86's segmentation).

--
Barry Margolin, ba****@alum.mit .edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

[Ben Pfaff]

Jack Klein <ja*******@spam cop.net> writes:

On Mon, 30 Aug 2004 00:21:31 GMT, pete <pf*****@mindsp ring.com> wrote
in comp.lang.c:

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?

Bases and offsets.

Can you provide any justification at all for your apparently
ridiculous assertion?

It's not too unreasonable if the "base" is the beginning of an
array and the "offset" is the number of elements from the base.
That's my mental model for abstract C arrays, anyway. It also
works for individual objects not within an array, which can be
treated with 1 element. It does break down when you're dealing
with e.g. structure members though.
--
int main(void){char p[]="ABCDEFGHIJKLM NOPQRSTUVWXYZab cdefghijklmnopq rstuvwxyz.\
\n",*q="kl BIcNBFr.NKEzjwC IxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+= strchr(p,*q++)-p;if(i>=(int)si zeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}

[Brian Inglis]

On Sun, 29 Aug 2004 19:07:12 -0700 in comp.std.c, Ben Pfaff
<bl*@cs.stanfor d.edu> wrote:

Jack Klein <ja*******@spam cop.net> writes:

On Mon, 30 Aug 2004 00:21:31 GMT, pete <pf*****@mindsp ring.com> wrote
in comp.lang.c:

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?

Bases and offsets.

Can you provide any justification at all for your apparently
ridiculous assertion?

It's not too unreasonable if the "base" is the beginning of an
array and the "offset" is the number of elements from the base.
That's my mental model for abstract C arrays, anyway. It also
works for individual objects not within an array, which can be
treated with 1 element. It does break down when you're dealing
with e.g. structure members though.

Nor really, the assertion still holds, structure member offsets are
then in addressing units (instead of number of elements) from the
structure base.

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

[pete]

Jack Klein wrote:

On Mon, 30 Aug 2004 00:21:31 GMT, pete <pf*****@mindsp ring.com> wrote
in comp.lang.c:

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?

Bases and offsets.

Can you provide any justification at all for your apparently
ridiculous assertion?

It's the way that pointers (addresses) relate to
each other with arithmetic and relational operators.
You can't add two pointers together,
because pointer types are not arithmetic types.
Relational operations for pointers, are only defined
for pointers which are offset from a common base.

The address of the lowest addressable byte of an object is
(char *)&object
and the address of the highest is
(char *)&object + sizeof object - 1

That's how I think of pointers.

--
pete

[E. Robert Tisdale]

j0mbolar wrote:

I've read in the standard that addresses
You probably mean pointers.
basically can't be interpreted as integers.
If they can, it is implementation defined behavior.
All that means is that the ANSI/ISO C standards
do not define any relationship between integers and pointers.
However, if they can't be viewed as integers
in any sense as far as portability goes,
As far as portability goes,
you can almost always count on the fact that
pointers have the same representation as an unsigned int --
a machine word. There are practically *no* exceptions
to this rule for most C programmers.
what, then, should one think of addresses being composed of?

A pointer is an object which may contain values
which are the addresses of valid objects.

[Douglas A. Gwyn]

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?

Think of them as consisting of (segment,offset )
pairs. Why do you care, so long as they work?