assigning array addresses to integer variables and vice versa

[anonymous]

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;

whereas I found it perfectly alright to do the following:

address = (int)&array;

Question 2:
What is the difference between array and &array. Are not they the same
thing i.e. starting
address of the array.

Question 3:

Why cannot I do array++. Is array a pointer constant?

Question 4:
How can I do the following:

array = address;

i.e. Give a new starting address to the array. Is it possible?

Thanks in advance for all Your replies.

A.

[pemo]

"anonymous" <ca******@yahoo.com> wrote in message
news:11*********************@z14g2000cwz.googlegro ups.com...

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;

whereas I found it perfectly alright to do the following:

address = (int)&array;

Question 2:
What is the difference between array and &array. Are not they the same
thing i.e. starting
address of the array.

Question 3:

Why cannot I do array++. Is array a pointer constant?

Question 4:
How can I do the following:

array = address;

i.e. Give a new starting address to the array. Is it possible?

Thanks in advance for all Your replies. Questions 1:
Why cannot I do the following: address = (int)array;
What do you by 'can't do'?

Question 2:
What is the difference between array and &array. Are not they the same
thing i.e. starting
an array name decomposes into the address of its first element, i.e., a
constant. 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'.

Question 3:

Why cannot I do array++. Is array a pointer constant?
Because an array name decomposes into the address of its first element, so
it's like saying 42++;

Question 4:
How can I do the following:

array = address;

You can't, it'd be like saying 42 = 24;

[Krishanu Debnath]

anonymous wrote:

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;
No, it is a legal syntax. However pointer to integer conversion may
invoke undefined behavior if result cannot be represented in integer
type.

whereas I found it perfectly alright to do the following:

address = (int)&array;

Question 2:
What is the difference between array and &array. Are not they the same
thing i.e. starting
address of the array.
array and &array are same in value context, both yield pointer to
first element in value context.

Question 3:

Why cannot I do array++. Is array a pointer constant?
postfix increment operator needs a modifiable l-value. array name is
not a modifiable l-value.

Question 4:
How can I do the following:

array = address;

i.e. Give a new starting address to the array. Is it possible?

No, see above.

Krishanu

[anonymous]

pemo wrote:

"anonymous" <ca******@yahoo.com> wrote in message
news:11*********************@z14g2000cwz.googlegro ups.com...

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;
whereas I found it perfectly alright to do the following:

address = (int)&array;

Question 2:
What is the difference between array and &array. Are not they the same
thing i.e. starting
address of the array.

Question 3:

Why cannot I do array++. Is array a pointer constant?

Question 4:
How can I do the following:

array = address;

i.e. Give a new starting address to the array. Is it possible?

Thanks in advance for all Your replies.

Questions 1:
Why cannot I do the following:

>address = (int)array;

What do you by 'can't do'?

Ooops, checking again, it is perfectly alright to do
address = (int)array;
My fault somewhere.

Question 2:
What is the difference between array and &array. Are not they the same
thing i.e. starting
an array name decomposes into the address of its first element, i.e., a
constant. 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'.

Why so liberty here when it keeps complaining all other times. I mean
the compiler :-)

Question 3:

Why cannot I do array++. Is array a pointer constant?

Because an array name decomposes into the address of its first element, so
it's like saying 42++;

Question 4:
How can I do the following:

array = address;

You can't, it'd be like saying 42 = 24;

Thanks for your help.

[Anand]

anonymous wrote:

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;

whereas I found it perfectly alright to do the following:

address = (int)&array;

Question 2:
What is the difference between array and &array. Are not they the same
thing i.e. starting
address of the array.

Question 3:

Why cannot I do array++. Is array a pointer constant?

Question 4:
How can I do the following:

array = address;

i.e. Give a new starting address to the array. Is it possible?

Thanks in advance for all Your replies.

A.

Search this group for numerous discussion about hazels of converting int
to pointer.

Standard has added special type intptr_t and uintptr_t to enable integer
types to hold object pointers.
Discussed in section:
"7.18.1.4 Integer types capable of holding object pointers".

But this is a *nice to have*, your compiler can decide not implement
this data type.

Again, this is only for the conversion from/to void.
To answer your specific questions.
Q1: Both are undefined behavior

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 ]

Q3&Q4: array is not an lvalue, see section:
6.3.2.1 Lvalues, arrays, and function designators
So you cannot modify it.
( Again the meaning of array changes the moment you pass it to
function)

--
(Welcome) http://www.ungerhu.com/jxh/clc.welcome.txt
(clc FAQ) http://www.eskimo.com/~scs/C-faq/top.html

[Suman]

pemo wrote:

"anonymous" <ca******@yahoo.com> wrote in message
news:11*********************@z14g2000cwz.googlegro ups.com... [snip]

Question 2:
What is the difference between array and &array. Are not they the same
thing i.e. starting

an array name decomposes into the address of its first element, i.e., a
constant.

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

And do search the archives.

[anonymous]

Anand wrote:

anonymous wrote:

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;

whereas I found it perfectly alright to do the following:

address = (int)&array;

Question 2:
What is the difference between array and &array. Are not they the same
thing i.e. starting
address of the array.

Question 3:

Why cannot I do array++. Is array a pointer constant?

Question 4:
How can I do the following:

array = address;

i.e. Give a new starting address to the array. Is it possible?

Thanks in advance for all Your replies.

A.
Search this group for numerous discussion about hazels of converting int
to pointer.

Standard has added special type intptr_t and uintptr_t to enable integer
types to hold object pointers.
Discussed in section:
"7.18.1.4 Integer types capable of holding object pointers".

But this is a *nice to have*, your compiler can decide not implement
this data type.

Again, this is only for the conversion from/to void.

I think no compiler has it implemented as yet ? Is this so?

To answer your specific questions.
Q1: Both are undefined behavior

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?

Q3&Q4: array is not an lvalue, see section:
6.3.2.1 Lvalues, arrays, and function designators
So you cannot modify it.
( Again the meaning of array changes the moment you pass it to
function)

--
(Welcome) http://www.ungerhu.com/jxh/clc.welcome.txt
(clc FAQ) http://www.eskimo.com/~scs/C-faq/top.html

Can I get a copy of the standard for download from somewhere?

Thanks in advance!

[Eric Sosman]

anonymous wrote:

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;
You can, if you like. The result will be useful on
some machines, useless on others. I wouldn't recommend it.
whereas I found it perfectly alright to do the following:

address = (int)&array;
That's equally legitimate, equally useful or useless.
Again, I wouldn't recommend it.
Question 2:
What is the difference between array and &array. Are not they the same
thing i.e. starting
address of the array.
This is Question 6.12 in the comp.lang.c Frequently Asked
Questions (FAQ) list

http://www.eskimo.com/~scs/C-faq/top.html
Question 3:

Why cannot I do array++. Is array a pointer constant?
FAQ Question 6.7.
Question 4:
How can I do the following:

array = address;

i.e. Give a new starting address to the array. Is it possible?
No.
Thanks in advance for all Your replies.

You're welcome. Read the FAQ; it will do you good.

--
Eric Sosman
es*****@acm-dot-org.invalid

[Eric Sosman]

Krishanu Debnath wrote:

array and &array are same in value context, both yield pointer to
first element in value context.

They are not the same. Both produce pointers, but
point to different objects. Please read the FAQ.

--
Eric Sosman
es*****@acm-dot-org.invalid

[Jordan Abel]

On 2005-11-24, Eric Sosman <es*****@acm-dot-org.invalid> wrote:

Krishanu Debnath wrote:

array and &array are same in value context, both yield pointer to
first element in value context.

They are not the same. Both produce pointers, but
point to different objects. Please read the FAQ.

They will compare equal, though, if converted to a void *

[because they point to the same memory location]

[Flash Gordon]

Suman wrote:

pemo wrote:

"anonymous" <ca******@yahoo.com> wrote in message
news:11*********************@z14g2000cwz.googlegro ups.com... [snip]

Question 2:
What is the difference between array and &array. Are not they the same
thing i.e. starting

an array name decomposes into the address of its first element, i.e., a
constant.

[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
*not* degenerate to a pointer. So the type of &array is pointer to
array, where as the type of pointer array degenerates to is pointer to
T. So they are different types.
And do search the archives.

Also check the FAQ where it will be far easier to find the correct
information.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

[Flash Gordon]

Krishanu Debnath wrote:

anonymous wrote:

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;
<snip>
Question 2:
What is the difference between array and &array. Are not they the same
thing i.e. starting
address of the array.

array and &array are same in value context, both yield pointer to
first element in value context.

No, they have different types. &array has the type pointer to array of
35 char, where as array degenerates to a pointer to char.

Check the comp.lang.c FAQ

<snip>
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

[Flash Gordon]

anonymous wrote:

Anand wrote:

anonymous wrote:

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;

whereas I found it perfectly alright to do the following:

address = (int)&array;

Question 2:
What is the difference between array and &array. Are not they the same
thing i.e. starting
address of the array.

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

Q3&Q4: array is not an lvalue, see section:
6.3.2.1 Lvalues, arrays, and function designators
So you cannot modify it.
( Again the meaning of array changes the moment you pass it to
function)

--
(Welcome) http://www.ungerhu.com/jxh/clc.welcome.txt
(clc FAQ) http://www.eskimo.com/~scs/C-faq/top.html

Can I get a copy of the standard for download from somewhere?

Google for n1124 and you will find the draft for C99 + all the
subsequent corrections. That and all the other publicly available copies
are at http://www.open-std.org/jtc1/sc22/wg14/www/docs/ or you can buy a
copy of the actual release version.

I think though that you really need to work through a good text book
though, such as K&R2, and also read the FAQ (the URL is above) which
will tell you what K&R2 is (in the Bibliography, I think).
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

[Keith Thompson]

Anand <An***@no-replies.com> writes:

anonymous wrote:

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;
whereas I found it perfectly alright to do the following:
address = (int)&array;
Question 2:
What is the difference between array and &array. Are not they the same
thing i.e. starting
address of the array.
Question 3:
Why cannot I do array++. Is array a pointer constant?
Question 4:
How can I do the following:
array = address;
i.e. Give a new starting address to the array. Is it possible?
Thanks in advance for all Your replies.
A.
Search this group for numerous discussion about hazels of converting
int to pointer.

Standard has added special type intptr_t and uintptr_t to enable
integer types to hold object pointers.
Discussed in section:
"7.18.1.4 Integer types capable of holding object pointers".

But this is a *nice to have*, your compiler can decide not implement
this data type.

Again, this is only for the conversion from/to void.
To answer your specific questions.
Q1: Both are undefined behavior

Converting a pointer to an integer *can* invoke undefined behavior.
Specifically:

Any pointer type may be converted to an integer type. Except as
previously specified, the result is implementation-defined. If the
result cannot be represented in the integer type, the behavior is
undefined. The result need not be in the range of values of any
integer type.
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 ]

As others have pointed out, they're not the same; they have different
types.

There's nothing special about function calls. An array expression is
implicitly converted to a pointer to its first element in *any*
context other than as the operand of a unary "&" or "sizeof", or when
it's a string literal in an initializer.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Jordan Abel]

On 2005-11-24, Keith Thompson <ks***@mib.org> wrote:

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 ]

As others have pointed out, they're not the same; they have different
types.

There's nothing special about function calls. An array expression is
implicitly converted to a pointer to its first element in *any*
context other than as the operand of a unary "&" or "sizeof", or when
it's a string literal in an initializer.

well, there _is_ one thing special about functions, but it pertains to
function prototypes, not funtion calls: the fact that declaring what
appears to be an array formal parameter is in fact a pointer formal
parameter [and thus, int main(int argc, char *argv[5]); is compatible
with int main(int argc, char **argv);, and sizeof argv == sizeof(char
**) in both cases, and not 5*sizeof(char *).]

[Randy Howard]

anonymous wrote
(in article
<11*********************@z14g2000cwz.googlegroups. com>):

I have couple of questions related to array addresses.

[snip]

What you are trying to do is going to cause you a lot of grief
in the long run. Do not make assumptions about the size of a
pointer being equivalent to the size of some other data type,
unless you are 100% sure that your code does not need to be
portable off-platform, including moving from 32-bit to 64-bit
environments. If you wish to pursue this, it's not appropriate
for comp.lang.c, which discusses standard C and portable
programming within that scope.

--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw

[Barry Schwarz]

On 24 Nov 2005 04:00:21 -0800, "anonymous" <ca******@yahoo.com> wrote:

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:
Others have answered
Question 2:
Ditto
Question 3:

Why cannot I do array++. Is array a pointer constant?
array is not a pointer at all. To prove this to yourself, print the
sizeof array as well as the sizeof several different types of
pointers. sizeof array must be 35 while sizeof(T*) for various types T
will usually be 4 or 8, depending on your system.

It is true that in certain circumstances an unsubscripted array name
in an expression will **evaluate to** the address of the first element
of the array with type pointer to element type but:

It does not create a pointer object in the same sense that a
definition such as "char *ptr;" does.

The resulting value is not a modifiable lvalue and cannot be the
operand of prefix or postfix ++.

Question 4:
How can I do the following:

array = address;

i.e. Give a new starting address to the array. Is it possible?

Not at all. And why would you ever want to? If you want to change
the contents of an entire array, you can use memcpy. If you want the
same code to process different arrays, you can use pointers.
<<Remove the del for email>>

[Eric Sosman]

Jordan Abel wrote:

On 2005-11-24, Eric Sosman <es*****@acm-dot-org.invalid> wrote:

Krishanu Debnath wrote:

array and &array are same in value context, both yield pointer to
first element in value context.

They are not the same. Both produce pointers, but
point to different objects. Please read the FAQ.

They will compare equal, though, if converted to a void *

[because they point to the same memory location]

True, but not particularly relevant. 0 == 0LL, but
that doesn't mean that `int' and `long long' are the same.

--
Eric Sosman
es*****@acm-dot-org.invalid

[Barry Schwarz]

On 24 Nov 2005 04:00:21 -0800, "anonymous" <ca******@yahoo.com> wrote:

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:
Others have answered
Question 2:
Ditto
Question 3:

Why cannot I do array++. Is array a pointer constant?
array is not a pointer at all. To prove this to yourself, print the
sizeof array as well as the sizeof several different types of
pointers. sizeof array must be 35 while sizeof(T*) for various types T
will usually be 4 or 8, depending on your system.

It is true that in certain circumstances an unsubscripted array name
in an expression will **evaluate to** the address of the first element
of the array with type pointer to element type but:

It does not create a pointer object in the same sense that a
definition such as "char *ptr;" does.

The resulting value is not a modifiable lvalue and cannot be the
operand of prefix or postfix ++.

Question 4:
How can I do the following:

array = address;

i.e. Give a new starting address to the array. Is it possible?

Not at all. And why would you ever want to? If you want to change
the contents of an entire array, you can use memcpy. If you want the
same code to process different arrays, you can use pointers.
<<Remove the del for email>>

[Mark McIntyre]

On 24 Nov 2005 04:00:21 -0800, in comp.lang.c , "anonymous"
<ca******@yahoo.com> wrote:

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?

whereas I found it perfectly alright to do the following:

address = (int)&array;
This is equally nonsensical. Your compiler won't complain though,
because this time the conversion is allowed - you're converting a
pointer to an array into an int. Its just a nonsensical conversion.
Question 2:
What is the difference between array and &array.
Array is the array. &array is the address of the start of array.
Are not they the same
thing i.e. starting address of the array.
They have different types, even though they may refer to the same
memory location.
Question 3:

Why cannot I do array++. Is array a pointer constant?
An array is an array. Its NOT a pointer.
Question 4:
How can I do the following:

array = address;

i.e. Give a new starting address to the array. Is it possible?

No. An array is an array. if you want a pointer, use a pointer.

And please read the FAQ, there's a big section about pointers.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Keith Thompson]

Mark McIntyre <ma**********@spamcop.net> writes:

On 24 Nov 2005 04:00:21 -0800, in comp.lang.c , "anonymous"
<ca******@yahoo.com> wrote:

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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Anand]

Flash Gordon wrote:

anonymous wrote:

Anand wrote:

anonymous wrote:

[...]

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

--
(Welcome) http://www.ungerhu.com/jxh/clc.welcome.txt
(clc FAQ) http://www.eskimo.com/~scs/C-faq/top.html

[Eric Sosman]

Anand wrote:

Flash Gordon wrote:

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.

--
Eric Sosman
es*****@acm-dot-org.invalid

[anonymous]

Eric Sosman wrote:

Anand wrote:

Flash Gordon wrote:

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.

--
Eric Sosman
es*****@acm-dot-org.invalid

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

Many thanks,

A.

[Mark McIntyre]

On Thu, 24 Nov 2005 23:29:10 GMT, in comp.lang.c , Keith Thompson
<ks***@mib.org> wrote:

Mark McIntyre <ma**********@spamcop.net> writes:

On 24 Nov 2005 04:00:21 -0800, in comp.lang.c , "anonymous"
<ca******@yahoo.com> wrote:

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.

Though not meaningfully.
The result isn't necessarily sensible.

quite.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Keith Thompson]

Mark McIntyre <ma**********@spamcop.net> writes:

On Thu, 24 Nov 2005 23:29:10 GMT, in comp.lang.c , Keith Thompson
<ks***@mib.org> wrote:

Mark McIntyre <ma**********@spamcop.net> writes:

On 24 Nov 2005 04:00:21 -0800, in comp.lang.c , "anonymous"
<ca******@yahoo.com> wrote:
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.

Though not meaningfully.

The result isn't necessarily sensible.

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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Mark McIntyre]

On Sat, 26 Nov 2005 21:25:15 GMT, in comp.lang.c , Keith Thompson
<ks***@mib.org> wrote:

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.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Suman]

Flash Gordon wrote:

Suman wrote:

pemo wrote:

"anonymous" <ca******@yahoo.com> wrote in message
news:11*********************@z14g2000cwz.googlegro ups.com...

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

Keith Thompson wrote:

Mark McIntyre <ma**********@spamcop.net> writes:

On Thu, 24 Nov 2005 23:29:10 GMT, in comp.lang.c , Keith Thompson
<ks***@mib.org> wrote:

Mark McIntyre <ma**********@spamcop.net> writes:
On 24 Nov 2005 04:00:21 -0800, in comp.lang.c , "anonymous"
<ca******@yahoo.com> wrote:
>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.

Though not meaningfully.

The result isn't necessarily sensible.

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.

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.