Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Address of array && address of pointer to array

Reply
Thread Tools

Address of array && address of pointer to array

 
 
James Kuyper
Guest
Posts: n/a
 
      09-15-2011
On 09/15/2011 08:22 AM, Stanley Rice wrote:
> On Sep 14, 9:41 pm, Ben Bacarisse <(E-Mail Removed)> wrote:
>> Stanley Rice <(E-Mail Removed)> writes:

....
>>> What's more, when we initialize the pointer to a function. we can both
>>> assign to the pointer with just a function name, as well as the
>>> address of the function name, using &(ampersand) operator. Why we
>>> could do so.

>>

> (snip)
>> "Why" is never easy in C. That's just the way it is: the name of a
>> function is converted to a pointer to that function except when the
>> function name is the operand of &. Thus fname and &fname are always the
>> same thing.

> So What you mean is that the compiler does most of things for us? I
> have tried to compare the address of function, say
>
> void foo() { }
>
> assert((void *)foo == (void *)&foo);
>
> and it passes. Is it the reason as the issue of the array talk above ?


No, the rule for arrays doesn't apply here. However, as he said above,
there is a similar rule for functions, and that is what makes this code
work.
 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      09-15-2011
Nobody <(E-Mail Removed)> writes:
> On Thu, 15 Sep 2011 05:36:48 -0700, Stanley Rice wrote:

[...]
>> Can we say that, two pointers must be equal if they are printed the same.

>
> No.


Yes.

> The format used by "%p" is implementation-dependent.


Correct.

> An
> implementation is free to print e.g. "?" for every pointer.


No, it isn't. The string printed by printf with "%p" must be readable
by scanf with "%p", and the result from scanf must compare equal to the
original pointer.

[...]

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      09-15-2011
Stanley Rice <(E-Mail Removed)> writes:
[...]
> So What you mean is that the compiler does most of things for us? I
> have tried to compare the address of function, say
>
> void foo() { }
>
> assert((void *)foo == (void *)&foo);
>
> and it passes. Is it the reason as the issue of the array talk above ?


That's not guaranteed to work. The behavior of converting a function
pointer to void* is not defined.

It's likely to work in practice (and I think POSIX requires it
to work), but there have been systems where function pointers are
bigger than void*, so the conversion could lose information.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Stanley Rice
Guest
Posts: n/a
 
      09-16-2011
On Sep 16, 3:26*am, pete <(E-Mail Removed)> wrote:
> James Kuyper wrote:
>
> > On 09/15/2011 08:22 AM, Stanley Rice wrote:
> > > So What you mean is that the compiler does most of things for us? I
> > > have tried to compare the address of function, say

>
> > > void foo() { }

>
> > > assert((void *)foo == (void *)&foo);

>
> > > and it passes. Is it the reason as the issue of the array talk above ?

>
> > No, the rule for arrays doesn't apply here. However, as he said above,
> > there is a similar rule for functions,
> > and that is what makes this code work.

>
> That code would be fine without the casts,
>
> * * assert(foo == &foo);
>
> but
> the result of a pointer to a function
> being cast to a pointer to an incomplete type such as (void *),
> is undefined.
>
> --
> pete


Err, I seems that I am just a novice and I don't fully understand the
pointer. Why should a pointer have to an object that has a specific
type, even,(void). Every code and variable and anything else just
store in the memory. Does the pointer with the specific type to point
to locate how much memory space to charge?

For example, a pointer points to type int means that 4 bytes of memory
is in the charge of the pointer, and a pointer points to type char
means that 1 byte of memory is in the charge of the pointer. In this
way, when we dereference a pointer that points to type int, we can get
a 4 byte integer, and when we dereference a pointer to char, we can
get one byte character. Is that right? And I wrote a testing program,
the snippet is as below:

int a = 48; // 48 represents character '0' in ASCII
int *b = &a;
char *c = (char *)b;
printf("%c\n", c); //2

The printf statement prints the character '0'. I guess the reason is
that,according to the little-endian priciple, integer 48 stores in the
side of least significant bit, but its memory address is lowest. When
I cast pointer b explicitly with (char *) to pointer c that points to
a char. The new pointer c, points to the original address where b ever
points to, but the difference is that, the pointer c that points to a
char can only in charge of one byte, that is, the lowest byte. so, '0'
is printed.

To prove my assumption, I try to change my code, In the first
statement, I change integer 48 to 304 (304 = 256 + 4, the least
sinificant byte is still hold integer 48, but the second least
significant byte hold an integer 1. In this way, the printf statement
still print character '0'.

So I guess the use of pointer pointed type is to determine how many
byte could this pointer in charge from the least significant byte. But
I don't know whether I'm right or not.

If my assumption is correct, then may be I can guess why casting a
pointer to function to void* is undefined. The pointer points to the
starting address of the function, without knowing the whole length of
the function, so the pointer doesn't know how many bytes could the
pointer in charge of, right?


 
Reply With Quote
 
Stanley Rice
Guest
Posts: n/a
 
      09-16-2011
On Sep 16, 2:51*am, Keith Thompson <(E-Mail Removed)> wrote:
> Stanley Rice <(E-Mail Removed)> writes:
>
> [...]
>
> > So What you mean is that the compiler does most of things for us? I
> > have tried to compare the address of function, say

>
> > void foo() { }

>
> > assert((void *)foo == (void *)&foo);

>
> > and it passes. Is it the reason as the issue of the array talk above ?

>
> That's not guaranteed to work. *The behavior of converting a function
> pointer to void* is not defined.



<snip>
> It's likely to work in practice (and I think POSIX requires it
> to work), but there have been systems where function pointers are
> bigger than void*, so the conversion could lose information.


I am not fully understand your meaning of "function pointers are
bigger than void *". I know it's not the size of the pointer. Do you
mean that how many bytes the pointer can in charge of? i.e. a pointer
points to int can in charge of 4 bytes and a pointer points to double
can in charge of 8 bytes, where a pointer to void can only in charge
of 1 byte.



 
Reply With Quote
 
Stanley Rice
Guest
Posts: n/a
 
      09-16-2011
On Sep 16, 3:26*am, pete <(E-Mail Removed)> wrote:
> James Kuyper wrote:
>
> > On 09/15/2011 08:22 AM, Stanley Rice wrote:
> > > So What you mean is that the compiler does most of things for us? I
> > > have tried to compare the address of function, say

>
> > > void foo() { }

>
> > > assert((void *)foo == (void *)&foo);

>
> > > and it passes. Is it the reason as the issue of the array talk above ?

>
> > No, the rule for arrays doesn't apply here. However, as he said above,
> > there is a similar rule for functions,
> > and that is what makes this code work.

>
> That code would be fine without the casts,
>
> * * assert(foo == &foo);
>
> but
> the result of a pointer to a function
> being cast to a pointer to an incomplete type such as (void *),
> is undefined.
>
> --
> pete


Err, I seems that I am just a novice and I don't fully understand the
pointer. Why should a pointer have to an object that has a specific
type, even,(void). Every code and variable and anything else just
store in the memory. Does the pointer with the specific type to point
to locate how much memory space to charge?

For example, a pointer points to type int means that 4 bytes of memory
is in the charge of the pointer, and a pointer points to type char
means that 1 byte of memory is in the charge of the pointer. In this
way, when we dereference a pointer that points to type int, we can get
a 4 byte integer, and when we dereference a pointer to char, we can
get one byte character. Is that right? And I wrote a testing program,
the snippet is as below:

int a = 48; // 48 represents character '0' in ASCII
int *b = &a;
char *c = (char *)b;
printf("%c\n", c); //2

The printf statement prints the character '0'. I guess the reason is
that,according to the little-endian priciple, integer 48 stores in the
side of least significant bit, but its memory address is lowest. When
I cast pointer b explicitly with (char *) to pointer c that points to
a char. The new pointer c, points to the original address where b ever
points to, but the difference is that, the pointer c that points to a
char can only in charge of one byte, that is, the lowest byte. so, '0'
is printed.

To prove my assumption, I try to change my code, In the first
statement, I change integer 48 to 304 (304 = 256 + 4, the least
sinificant byte is still hold integer 48, but the second least
significant byte hold an integer 1. In this way, the printf statement
still print character '0'.

So I guess the use of pointer pointed type is to determine how many
byte could this pointer in charge from the least significant byte. But
I don't know whether I'm right or not.

If my assumption is correct, then may be I can guess why casting a
pointer to function to void* is undefined. The pointer points to the
starting address of the function, without knowing the whole length of
the function, so the pointer doesn't know how many bytes could the
pointer in charge of, right?
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      09-16-2011
On 09/15/2011 09:13 PM, Stanley Rice wrote:
> On Sep 16, 2:51´┐Żam, Keith Thompson <(E-Mail Removed)> wrote:

....
>> It's likely to work in practice (and I think POSIX requires it
>> to work), but there have been systems where function pointers are
>> bigger than void*, so the conversion could lose information.

>
> I am not fully understand your meaning of "function pointers are
> bigger than void *". I know it's not the size of the pointer.


You "know" incorrectly. Function pointers can have a size that is
different from the size of void*, and there have been many systems where
this is indeed the case.
--
James Kuyper
 
Reply With Quote
 
Stanley Rice
Guest
Posts: n/a
 
      09-16-2011

<snip>
> >> Can we say that, two pointers must be equal if they are printed the same.

>
> > No.

>
> Yes.

How to print the address of a pointer is implementation dependant,
based on how to represent the pointer. Now I can understand two
pointers point to the same memory location may print differently.

But is it possible that two different pointers that point two
different address print the same. Just as Ben Bacarisse ever reply
"Once converted the pointers will compare equal but even equal
pointers might print differently"



 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      09-16-2011
Stanley Rice <(E-Mail Removed)> writes:
> On Sep 16, 3:26┬*am, pete <(E-Mail Removed)> wrote:
>> James Kuyper wrote:
>>
>> > On 09/15/2011 08:22 AM, Stanley Rice wrote:
>> > > So What you mean is that the compiler does most of things for us? I
>> > > have tried to compare the address of function, say

>>
>> > > void foo() { }

>>
>> > > assert((void *)foo == (void *)&foo);

>>
>> > > and it passes. Is it the reason as the issue of the array talk above ?

>>
>> > No, the rule for arrays doesn't apply here. However, as he said above,
>> > there is a similar rule for functions,
>> > and that is what makes this code work.

>>
>> That code would be fine without the casts,
>>
>> ┬* ┬* assert(foo == &foo);
>>
>> but
>> the result of a pointer to a function
>> being cast to a pointer to an incomplete type such as (void *),
>> is undefined.
>>
>> --
>> pete

>
> Err, I seems that I am just a novice and I don't fully understand the
> pointer. Why should a pointer have to an object that has a specific
> type, even,(void). Every code and variable and anything else just
> store in the memory. Does the pointer with the specific type to point
> to locate how much memory space to charge?


The type of a pointer is generally a compile-time concept. For example,
given:

short *p1;
double *p2;

p1 and p2 *might* have the same size and representation, but they're of
different types. That means, among other things, that the expression
``*p1'' is of type short, the expression ``*p2'' is of type double, and
the assignment ``p1 = p2'' is invalid, since the types are incompatible.
(I'm not using the term "incompatible" quite the same way the standard
does.)

And consider a system where int and long have exactly the same size and
representation (say they're both 4 bytes). int* and long* are still two
distinct types, and the compiler won't allow you to assign one to the
other without a cast (or at least it will warn you if you attempt to do
so). There's more to type than size.

> For example, a pointer points to type int means that 4 bytes of memory
> is in the charge of the pointer, and a pointer points to type char
> means that 1 byte of memory is in the charge of the pointer.


Pretty much, though I'm not sure what "in the charge of" means
here. Also, an int isn't necessarily 4 bytes, though a char is by
definition 1 byte (but a byte can be more than 8 bits).

> In this
> way, when we dereference a pointer that points to type int, we can get
> a 4 byte integer, and when we dereference a pointer to char, we can
> get one byte character. Is that right? And I wrote a testing program,
> the snippet is as below:
>
> int a = 48; // 48 represents character '0' in ASCII


ASCII is not the only character set; this would be better written as
int a = '0';

> int *b = &a;
> char *c = (char *)b;


This is not reliable. It causes c to point to the first byte of a;
that's not necessarily the low-order byte.

> printf("%c\n", c); //2


I think you meant

printf("%c\n", *c);

> The printf statement prints the character '0'. I guess the reason is
> that,according to the little-endian priciple, integer 48 stores in the
> side of least significant bit, but its memory address is lowest. When
> I cast pointer b explicitly with (char *) to pointer c that points to
> a char. The new pointer c, points to the original address where b ever
> points to, but the difference is that, the pointer c that points to a
> char can only in charge of one byte, that is, the lowest byte. so, '0'
> is printed.


Yes, but little-endianness is not a principle, it's merely an
implementation choice.

> To prove my assumption, I try to change my code, In the first
> statement, I change integer 48 to 304 (304 = 256 + 4, the least
> sinificant byte is still hold integer 48, but the second least
> significant byte hold an integer 1. In this way, the printf statement
> still print character '0'.
>
> So I guess the use of pointer pointed type is to determine how many
> byte could this pointer in charge from the least significant byte. But
> I don't know whether I'm right or not.


It's the lowest addressed byte, not necessarily the least significant
byte.

> If my assumption is correct, then may be I can guess why casting a
> pointer to function to void* is undefined. The pointer points to the
> starting address of the function, without knowing the whole length of
> the function, so the pointer doesn't know how many bytes could the
> pointer in charge of, right?


A function pointer isn't necessarily the memory address of the start
of the function. On most systems you're likely to use, it probably
will be, but the standard doesn't guarantee it. For example, it
could be an index into a table of all the functions in your program.
Or it could contain additional system-specific information. (As I
recall, function pointers on the IBM AS/400 are something like
16 bytes, though it's very likely I've got the details wrong.)
The standard only requires that function pointers work the way
they're supposed to: you can call functions through them, distinct
functions have distinct addresses, and so on.

Conversion from a function pointer to void* is undefined simply
because the standard doesn't define it -- and the reason for that
is that any definition could make a correct implementation difficult
or impossible on some systems.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      09-16-2011
Stanley Rice <(E-Mail Removed)> writes:

> <snip>
>> >> Can we say that, two pointers must be equal if they are printed the same.

>>
>> > No.

>>
>> Yes.

> How to print the address of a pointer is implementation dependant,
> based on how to represent the pointer. Now I can understand two
> pointers point to the same memory location may print differently.


Yup.

> But is it possible that two different pointers that point two
> different address print the same.


No. The only restriction on what %p produces is that it can be used to
recover the address if read back in using one of the scanf functions.
If two unequal pointers "printed the same" they'd read the same and that
is not permitted.

> Just as Ben Bacarisse ever reply
> "Once converted the pointers will compare equal but even equal
> pointers might print differently"


I am not sure what your point is about this quote from me. What it says
is very similar to the second sentence of your first paragraph

--
Ben.
 
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
pointer to an array vs pointer to pointer subramanian100in@yahoo.com, India C Programming 5 09-23-2011 10:28 AM
Pointer to array of array of const pointer RSL C++ 14 02-19-2010 02:06 PM
Array of pointer and pointer of array erfan C Programming 6 01-28-2008 08:55 PM
passing the address of a pointer to a func that doesnt recieve a pointer-to-a-pointer jimjim C Programming 16 03-27-2006 11:03 PM
Array of pointer Vs Pointer to Array sangeetha C Programming 9 10-09-2004 07:01 PM



Advertisments