assigning array addresses to integer variables and vice versa

[Keith Thompson]

I have couple of questions related to array addresses. As they belong
to the same block, I
am putting them here in one single post. I hope nobody minds:

char array[35];

int address;

Questions 1:
Why cannot I do the following:

address = (int)array;

Because its nonsensical. How can you convert an array to an integer?

No, it's not quite nonsensical. The array name is implicitly
converted to a pointer to its first element, and a pointer can legally
be converted to an integer. The result isn't necessarily sensible.

 

[Anand]

[...]

Q2: Both means the same i.e. address of the first element.
[ However the moment you pass an array to a function, the meaning
changes, and hence meaning of array and &array differs there ]

Can you be more elaborate on this please?

It's not quite right. &array is always different from array, they differ
in type. So, given your definition above, the compiler *must* complain
if you pass &array to a function with a prototype in scope specifying a
pointer to char. E.g.

#include <string.h>
int main(void)
{
char array[35] = "hello";
size_t len1 = strlen(array); /* this is allowed */
size_t len2 = strlen(&array); /* The compiler is required to complain */
}

&array has type pointer to array, where as array otherwise degenerates
to a pointer to char.

[...]
Eaaach.. bad mistake from my side!!!

It so happened that in my compiler, the _values_ of array and &array
were same. So without using much of my gray matter I replied stating
array and &array are same.
(Again when I was talking about function.. I meant the _values_ specific
to my compiler's implementation.)

 

[Eric Sosman]

It's not quite right. &array is always different from array, they
differ in type. So, given your definition above, the compiler *must*
complain if you pass &array to a function with a prototype in scope
specifying a pointer to char. [...]

Eaaach.. bad mistake from my side!!!

It so happened that in my compiler, the _values_ of array and &array
were same. So without using much of my gray matter I replied stating
array and &array are same.
(Again when I was talking about function.. I meant the _values_ specific
to my compiler's implementation.)

The point a lot of people seem to miss (not just in
this thread, but in many others like it, which is why there's
a FAQ on the topic) is that in C there is no such thing as a
typeless value. A value in C always has a type, and cannot
be divorced from its type.

There is no direct way to compare values of different
types (or perhaps I should say "really different" types,
since qualifiers like `const' don't matter). The `=='
operator requires that both operands be of the same type.
If they start out as different types, one or both must
undergo conversion until new derived values of a common
type are found. These derived values are not the same as
the originals, because their types are different from those
of the originals.

For some reason people seem more prone to overlook this
matter when thinking about pointers than when thinking about
other types. Nobody thinks 42 and 42L and 42LL and 42.0f
and 42.0 and 42.0L are the same, yet confusion over `array'
and `&array' persists. I speculate that this may be because
people think of pointers as addresses when in fact they are
more: they are "typed addresses," addresses plus information.
The address tells you where to find something in memory, while
the type information tells you how to understand what you find
there.

True, in most implementations the extra information is
implicit and does not show up in something like a core dump --
but that's not unusual. There's lots of implicit information
floating around in a compiled program that a core dump won't
reveal. If a core dump or debugger tells you that some variable
holds `FEDCBA98', can you tell what value is represented? No.
Can you tell whether the value is positive or negative? No,
you can't even tell whether the concept of "sign" makes any
sense for this variable. Without knowledge of the type, you
have no idea how to make sense of this batch of bare hex digits.
In C, type and value are inseparable.

 

[anonymous]

It's not quite right. &array is always different from array, they
differ in type. So, given your definition above, the compiler *must*
complain if you pass &array to a function with a prototype in scope
specifying a pointer to char. [...]

Eaaach.. bad mistake from my side!!!

It so happened that in my compiler, the _values_ of array and &array
were same. So without using much of my gray matter I replied stating
array and &array are same.
(Again when I was talking about function.. I meant the _values_ specific
to my compiler's implementation.)

The point a lot of people seem to miss (not just in
this thread, but in many others like it, which is why there's
a FAQ on the topic) is that in C there is no such thing as a
typeless value. A value in C always has a type, and cannot
be divorced from its type.

There is no direct way to compare values of different
types (or perhaps I should say "really different" types,
since qualifiers like `const' don't matter). The `=='
operator requires that both operands be of the same type.
If they start out as different types, one or both must
undergo conversion until new derived values of a common
type are found. These derived values are not the same as
the originals, because their types are different from those
of the originals.

For some reason people seem more prone to overlook this
matter when thinking about pointers than when thinking about
other types. Nobody thinks 42 and 42L and 42LL and 42.0f
and 42.0 and 42.0L are the same, yet confusion over `array'
and `&array' persists. I speculate that this may be because
people think of pointers as addresses when in fact they are
more: they are "typed addresses," addresses plus information.
The address tells you where to find something in memory, while
the type information tells you how to understand what you find
there.

True, in most implementations the extra information is
implicit and does not show up in something like a core dump --
but that's not unusual. There's lots of implicit information
floating around in a compiled program that a core dump won't
reveal. If a core dump or debugger tells you that some variable
holds `FEDCBA98', can you tell what value is represented? No.
Can you tell whether the value is positive or negative? No,
you can't even tell whether the concept of "sign" makes any
sense for this variable. Without knowledge of the type, you
have no idea how to make sense of this batch of bare hex digits.
In C, type and value are inseparable.

Really a thorough and kind of reply I needed. All other replies
contributed to my knowledge
as well.

Many thanks,

A.

 

[Mark McIntyre]

No, it's not quite nonsensical. The array name is implicitly
converted to a pointer to its first element, and a pointer can legally
be converted to an integer.

Though not meaningfully.

The result isn't necessarily sensible.

quite.

 

[Keith Thompson]

Though not meaningfully.


quite.

I'm not quite sure I see the point of your followup. I wrote,
correctly, that the result isn't necessarily sensible; you seem to be
saying that the result can never be meaningful, which, strictly
speaking, is untrue.

See footnote 56 in C99 6.3.2.3:

The mapping functions for converting a pointer to an integer or an
integer to a pointer are intended to be consistent with the
addressing structure of the execution environment.

The conversion is non-portable and often not useful; an unqualified
"not meaningfully" is an overstatement.

 

[Mark McIntyre]

I'm not quite sure I see the point of your followup.

I'm generally agreeing with you. Is that disallowed?

The conversion is non-portable and often not useful; an unqualified
"not meaningfully" is an overstatement.

If we were in a platform specific group, I'd agree on that point too.

In this group, where code is supposed to be portable and
platform-independent, I can't. As I'm sure you'd agree, the conversion
would be horribly meaningless on a platform with 32-bit ints and
64-bit addresses.

Of course, if you want to be argumentative, we could be here for
weeks.

 

[Suman]

news:[email protected]... [snip]
Question 2:
What is the difference between array and &array. Are not they the same
thing

[snip]

Well, almost.

You obviously cannot take the address of a 'value', and so &array
doesn't make sense, and I assume the compiler's saying to itself 'well, ok,
I know what he means'.

In a value context, an object of type "array N of T" becomes
a value of type "pointer to T", pointing to the first element
of that array, i.e., the one with subscript 0.

Not when it is the operand of either sizeof or the unary &, then it does

....

Yes, of course, which is why I wrote almost in the first place. I
thought it
would be instructive to let the OP find out from the archives than to
repeat.
So much for laziness.

 

[anonymous]

I'm not quite sure I see the point of your followup. I wrote,
correctly, that the result isn't necessarily sensible; you seem to be
saying that the result can never be meaningful, which, strictly
speaking, is untrue.

See footnote 56 in C99 6.3.2.3:

The mapping functions for converting a pointer to an integer or an
integer to a pointer are intended to be consistent with the
addressing structure of the execution environment.

The conversion is non-portable and often not useful; an unqualified
"not meaningfully" is an overstatement.

I think I can follow the point you are trying to make. The conversion
is allowed.
However, it results in unportable code and the behavior may be
undefined under certain
circumstances.

Thanks for your reply.

A.