Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > assigning array addresses to integer variables and vice versa

Reply
Thread Tools

assigning array addresses to integer variables and vice versa

 
 
Keith Thompson
Guest
Posts: n/a
 
      11-24-2005
Mark McIntyre <(E-Mail Removed)> writes:
> On 24 Nov 2005 04:00:21 -0800, in comp.lang.c , "anonymous"
> <(E-Mail Removed)> 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) http://www.velocityreviews.com/forums/(E-Mail Removed) <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.
 
Reply With Quote
 
 
 
 
Anand
Guest
Posts: n/a
 
      11-25-2005
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
 
Reply With Quote
 
 
 
 
Eric Sosman
Guest
Posts: n/a
 
      11-25-2005
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
(E-Mail Removed)lid
 
Reply With Quote
 
anonymous
Guest
Posts: n/a
 
      11-25-2005

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
> (E-Mail Removed)lid


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

Many thanks,

A.

 
Reply With Quote
 
Mark McIntyre
Guest
Posts: n/a
 
      11-26-2005
On Thu, 24 Nov 2005 23:29:10 GMT, in comp.lang.c , Keith Thompson
<(E-Mail Removed)> wrote:

>Mark McIntyre <(E-Mail Removed)> writes:
>> On 24 Nov 2005 04:00:21 -0800, in comp.lang.c , "anonymous"
>> <(E-Mail Removed)> 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 =----
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      11-26-2005
Mark McIntyre <(E-Mail Removed)> writes:
> On Thu, 24 Nov 2005 23:29:10 GMT, in comp.lang.c , Keith Thompson
> <(E-Mail Removed)> wrote:
>>Mark McIntyre <(E-Mail Removed)> writes:
>>> On 24 Nov 2005 04:00:21 -0800, in comp.lang.c , "anonymous"
>>> <(E-Mail Removed)> 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) (E-Mail Removed) <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.
 
Reply With Quote
 
Mark McIntyre
Guest
Posts: n/a
 
      11-27-2005
On Sat, 26 Nov 2005 21:25:15 GMT, in comp.lang.c , Keith Thompson
<(E-Mail Removed)> 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 =----
 
Reply With Quote
 
Suman
Guest
Posts: n/a
 
      11-29-2005

Flash Gordon wrote:
> Suman wrote:
> > pemo wrote:
> >> "anonymous" <(E-Mail Removed)> wrote in message
> >> news:(E-Mail Removed) 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.

 
Reply With Quote
 
anonymous
Guest
Posts: n/a
 
      11-29-2005

Keith Thompson wrote:
> Mark McIntyre <(E-Mail Removed)> writes:
> > On Thu, 24 Nov 2005 23:29:10 GMT, in comp.lang.c , Keith Thompson
> > <(E-Mail Removed)> wrote:
> >>Mark McIntyre <(E-Mail Removed)> writes:
> >>> On 24 Nov 2005 04:00:21 -0800, in comp.lang.c , "anonymous"
> >>> <(E-Mail Removed)> 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.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
converting int and short to byte array and vice versa carmen Java 4 01-12-2010 05:00 PM
converting floating point number to integer and vice versa FPGA VHDL 5 01-08-2008 06:29 AM
Safe conversion from floating real to integer (and vice versa) rz0 C Programming 4 02-01-2006 05:27 PM
Howto display an ASP.net datagrid rows as columns and vice versa? Jimmy ASP .Net 1 06-14-2005 03:30 PM
CString to char array convertion (vice versa) Tim Wong C++ 5 01-21-2005 05:09 AM



Advertisments