Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #10220 > unrolled thread

Address of array && address of pointer to array

Back to article view | Back to comp.lang.c

Contents

  Address of array && address of pointer to array Stanley Rice <heconghui@gmail.com> - 2011-09-14 06:12 -0700
    Re: Address of array && address of pointer to array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-09-14 14:41 +0100
      Re: Address of array && address of pointer to array Paul N <gw7rib@aol.com> - 2011-09-14 14:15 -0700
      Re: Address of array && address of pointer to array Peter Nilsson <airia@acay.com.au> - 2011-09-14 19:25 -0700
        Re: Address of array && address of pointer to array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-09-15 10:54 +0100
          Re: Address of array && address of pointer to array Stanley Rice <heconghui@gmail.com> - 2011-09-15 05:36 -0700
            Re: Address of array && address of pointer to array Ike Naar <ike@sverige.freeshell.org> - 2011-09-15 13:46 +0000
            Re: Address of array && address of pointer to array Nobody <nobody@nowhere.com> - 2011-09-15 14:48 +0100
              Re: Address of array && address of pointer to array Keith Thompson <kst-u@mib.org> - 2011-09-15 10:28 -0700
                Re: Address of array && address of pointer to array Stanley Rice <heconghui@gmail.com> - 2011-09-15 18:23 -0700
                  Re: Address of array && address of pointer to array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-09-16 12:58 +0100
                  Re: Address of array && address of pointer to array James Kuyper <jameskuyper@verizon.net> - 2011-09-16 08:03 -0400
                Re: Address of array && address of pointer to array Nobody <nobody@nowhere.com> - 2011-09-16 13:09 +0100
                  Re: Address of array && address of pointer to array Keith Thompson <kst-u@mib.org> - 2011-09-16 12:05 -0700
                    Re: Address of array && address of pointer to array gazelle@shell.xmission.com (Kenny McCormack) - 2011-09-16 19:35 +0000
                    Re: Address of array && address of pointer to array Peter Nilsson <airia@acay.com.au> - 2011-09-19 15:45 -0700
                      Re: Address of array && address of pointer to array Keith Thompson <kst-u@mib.org> - 2011-09-19 17:47 -0700
            Re: Address of array && address of pointer to array James Kuyper <jameskuyper@verizon.net> - 2011-09-15 10:21 -0400
      Re: Address of array && address of pointer to array Stanley Rice <heconghui@gmail.com> - 2011-09-15 05:22 -0700
        Re: Address of array && address of pointer to array James Kuyper <jameskuyper@verizon.net> - 2011-09-15 10:23 -0400
          Re: Address of array && address of pointer to array pete <pfiland@mindspring.com> - 2011-09-15 15:26 -0400
            Re: Address of array && address of pointer to array Stanley Rice <heconghui@gmail.com> - 2011-09-15 18:14 -0700
              Re: Address of array && address of pointer to array Keith Thompson <kst-u@mib.org> - 2011-09-16 02:09 -0700
                Re: Address of array && address of pointer to array James Kuyper <jameskuyper@verizon.net> - 2011-09-16 08:39 -0400
                Re: Address of array && address of pointer to array pete <pfiland@mindspring.com> - 2011-09-16 18:08 -0400
              Re: Address of array && address of pointer to array Bart van Ingen Schenau <bart@ingen.ddns.info> - 2011-09-16 16:38 +0200
                Re: Address of array && address of pointer to array cri@tiac.net (Richard Harter) - 2011-09-16 22:04 +0000
            Re: Address of array && address of pointer to array Stanley Rice <heconghui@gmail.com> - 2011-09-15 18:08 -0700
              Re: Address of array && address of pointer to array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-09-16 13:12 +0100
              Re: Address of array && address of pointer to array James Kuyper <jameskuyper@verizon.net> - 2011-09-16 08:30 -0400
        Re: Address of array && address of pointer to array Keith Thompson <kst-u@mib.org> - 2011-09-15 11:51 -0700
          Re: Address of array && address of pointer to array Stanley Rice <heconghui@gmail.com> - 2011-09-15 18:13 -0700
            Re: Address of array && address of pointer to array James Kuyper <jameskuyper@verizon.net> - 2011-09-15 21:18 -0400
              Re: Address of array && address of pointer to array Stanley Rice <heconghui@gmail.com> - 2011-09-16 05:37 -0700
                Re: Address of array && address of pointer to array James Kuyper <jameskuyper@verizon.net> - 2011-09-16 09:46 -0400
                Re: Address of array && address of pointer to array Keith Thompson <kst-u@mib.org> - 2011-09-16 12:08 -0700
            Re: Address of array && address of pointer to array Nobody <nobody@nowhere.com> - 2011-09-16 13:20 +0100

Page 1 of 2  [1] 2  Next page →

#10220 — Address of array && address of pointer to array

Hello all

I am confused of array and pointer these days, and wrote some testing
program. one of the snippet is as below:

int A[3];

printf("%p\n", A);          //   1
printf("%p\n", &A);         //   2
printf("%p\n", A + 1);      //   3
printf("%p\n", &A + 1);     //   4

It shows that the result of first and second statement is the same,
while the result of statement 3 and statement 4 is different. I can
understand the difference of result 3 and result 4, as if the pointer
to arrays are of different levels. But why the statement 1 and
statement 2 generate the same result?

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.

Thanks for answering.

[toc] | [next] | [standalone]

#10222

Stanley Rice <heconghui@gmail.com> writes:

> I am confused of array and pointer these days, and wrote some testing
> program. one of the snippet is as below:
>
> int A[3];
>
> printf("%p\n", A);          //   1
> printf("%p\n", &A);         //   2
> printf("%p\n", A + 1);      //   3
> printf("%p\n", &A + 1);     //   4
>
> It shows that the result of first and second statement is the same,
> while the result of statement 3 and statement 4 is different. I can
> understand the difference of result 3 and result 4, as if the pointer
> to arrays are of different levels. But why the statement 1 and
> statement 2 generate the same result?

Nit: convert the pointers to (void *) because that's what %p expects.
If you do that, 1 and 2 will always produce the same result no matter
what type the array has.  I've used a machine where they won't always be
the same if the type of A is char[3].

The differences and potential differences come from the fact that A and
&A are different things.  When an array is used in most contexts, it is
converted to a pointer to its first element.  Being the operand of the
& operator is an exception to this rule.  So in case 1, A is an 'int *'
and in case 2, &A is a pointer to the whole array (the type is
'int (*)[3]' if you are interested in the details).

On most systems, a pointer to the start of an array and a pointer to the
whole array will print the same using %p and they are guaranteed to be
the same when converted to a common type.  I.e.

  (void *)A == (void *)&A[0] && (void *)A == (void *)&A

is always true.  The types are different and that means that they may
have different representations so %p might print different things for
in your unconverted printf calls (1 and 2).

The difference in 3 and 4 is due to the "levels" as you put it.  Adding
to a pointer adds the size of the thing pointed to.  A + 1 adds one to
an int * producing a pointer to A[1].  In fact, A[n] is defined to be
*(A + n).  &A + 1 produces a pointer that points just past the end of
the array A.

I thought this might be FAQ (http://c-faq.com/) but I could not find the
right answer there .  Even so, read section 6 about arrays and pointers
-- it's good stuff.

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

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

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#10252

On Sep 14, 2:41 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> Stanley Rice <hecong...@gmail.com> writes:
> > I am confused of array and pointer these days, and wrote some testing
> > program. one of the snippet is as below:
>
> > int A[3];
>
> > printf("%p\n", A);          //   1
> > printf("%p\n", &A);         //   2
> > printf("%p\n", A + 1);      //   3
> > printf("%p\n", &A + 1);     //   4
>
> > It shows that the result of first and second statement is the same,
> > while the result of statement 3 and statement 4 is different. I can
> > understand the difference of result 3 and result 4, as if the pointer
> > to arrays are of different levels. But why the statement 1 and
> > statement 2 generate the same result?

(snip)

> I thought this might be FAQ (http://c-faq.com/) but I could not find the
> right answer there .  Even so, read section 6 about arrays and pointers
> -- it's good stuff.

Yes, 6.12 is the one. Though I managed to miss it too, and only found
it by remembering the wording and using Google!

[toc] | [prev] | [next] | [standalone]

#10265

Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> Stanley Rice <hecong...@gmail.com> writes:
> > int A[3];
> >
> > printf("%p\n", A);          //   1
> > printf("%p\n", &A);         //   2
> > printf("%p\n", A + 1);      //   3
> > printf("%p\n", &A + 1);     //   4
<snip>
>
> Nit: convert the pointers to (void *) because that's what %p
> expects.

True.

> If you do that, 1 and 2 will always produce the same result no
> matter what type the array has.

That's not true. If the OP wants to know if they compare equal,
then the equality operater should be used. There is no guarantee
that %p prints exactly the same thing, even for pointer arguments
with the same representation. [e.g segmented architectures.]

The only guarantee is that if you read the output with scanf (et
al,) the conversion will compare equal with the original pointer
(if its lifetime hasn't expired.)

<snip>

--
Peter

[toc] | [prev] | [next] | [standalone]

#10273

Peter Nilsson <airia@acay.com.au> writes:

> Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>> Stanley Rice <hecong...@gmail.com> writes:
>> > int A[3];
>> >
>> > printf("%p\n", A);          //   1
>> > printf("%p\n", &A);         //   2
>> > printf("%p\n", A + 1);      //   3
>> > printf("%p\n", &A + 1);     //   4
> <snip>
>>
>> Nit: convert the pointers to (void *) because that's what %p
>> expects.
>
> True.
>
>> If you do that, 1 and 2 will always produce the same result no
>> matter what type the array has.
>
> That's not true. If the OP wants to know if they compare equal,
> then the equality operater should be used. There is no guarantee
> that %p prints exactly the same thing, even for pointer arguments
> with the same representation. [e.g segmented architectures.]

Good point.  Once converted the pointers will compare equal but even
equal pointers might print differently. 

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#10279

On Sep 15, 5:54 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> Peter Nilsson <ai...@acay.com.au> writes:
> > Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> >> Stanley Rice <hecong...@gmail.com> writes:
> >> > int A[3];
>
> >> > printf("%p\n", A);          //   1
> >> > printf("%p\n", &A);         //   2
> >> > printf("%p\n", A + 1);      //   3
> >> > printf("%p\n", &A + 1);     //   4
> > <snip>
>
> >> Nit: convert the pointers to (void *) because that's what %p
> >> expects.
>
> > True.
>
> >> If you do that, 1 and 2 will always produce the same result no
> >> matter what type the array has.
>
> > That's not true. If the OP wants to know if they compare equal,
> > then the equality operater should be used. There is no guarantee
> > that %p prints exactly the same thing, even for pointer arguments
> > with the same representation. [e.g segmented architectures.]



<snip>
> Good point.  Once converted the pointers will compare equal but even
> equal pointers might print differently.

Thanks for you replying. But I am sorry that I am not fully understand
that.

1. when we use %p to print the pointer, but the argument is not
explicitly converted, will it implicitly be converted to (void *)
type?
2. Why the equal pointers will print differently? It's machine
dependent or anything else? Can we say that, two pointers must be
equal if they are printed the same.
3. In my previous post. If I change my code:
    printf("the address of A+1: %p\n", (void *)A+1);     // 3'
    printf("the address of &A+1: %p\n", (void *)&A+1);   // 4'

statement 3' and 4' will print the same thing. Why it that compared to
my original code, without explicitly cast.

[toc] | [prev] | [next] | [standalone]

#10281

On 2011-09-15, Stanley Rice <heconghui@gmail.com> wrote:
> 1. when we use %p to print the pointer, but the argument is not
> explicitly converted, will it implicitly be converted to (void *)
> type?

No.

> 2. Why the equal pointers will print differently? It's machine
> dependent or anything else? Can we say that, two pointers must be
> equal if they are printed the same.

Imagine a cpu architecture where pointers are represented by a pair
(base,offset) where the effective memory address is obtained by

    address = 16 * base + offset

The pointer (2,25) represents effective memory address 16 * 2 * 25 = 57 .
The pointer (3,9) represents effective memory address 16 * 3 + 9 = 57 .
These two pointers could print differently (say, "2:25" vs. "3:9") but
compare equal (57 vs. 57).

> 3. In my previous post. If I change my code:
>     printf("the address of A+1: %p\n", (void *)A+1);     // 3'
>     printf("the address of &A+1: %p\n", (void *)&A+1);   // 4'

Beware: (void *)A+1  is parsed as  ((void *)A) + 1  which is
not correct C (one cannot perform arithmetic on a pointer to void)
although gcc will probably accept it as an extension.

You probably meant  (void *) (A+1)

[toc] | [prev] | [next] | [standalone]

#10282

On Thu, 15 Sep 2011 05:36:48 -0700, Stanley Rice wrote:

> 1. when we use %p to print the pointer, but the argument is not
> explicitly converted, will it implicitly be converted to (void *)
> type?

No. The compiler doesn't know the types of printf's arguments (other than
the first one), so it can't know that it should be a void*.

> 2. Why the equal pointers will print differently? It's machine
> dependent or anything else?

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

One reason why equal pointers might print differently is if there are
multiple representations which are considered equal, and the output for
"%p" is based upon the representation without any form of normalisation.

E.g. on 8086, a (far) pointer contains a 16-bit segment and a 16-bit
offset. The actual memory address is "segment * 16 + offset", so e.g.
0100:2300 and 0200:1300 both refer to the address 0x03300. If
comparison normalises the pointers, they will compare equal. If printing
uses the raw representation, they will print differently.

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

No. The format used by "%p" is implementation-dependent. An
implementation is free to print e.g. "?" for every pointer.

> 3. In my previous post. If I change my code:
>     printf("the address of A+1: %p\n", (void *)A+1);     // 3'
>     printf("the address of &A+1: %p\n", (void *)&A+1);   // 4'
> 
> statement 3' and 4' will print the same thing. Why it that compared to
> my original code, without explicitly cast.

You're relying upon a implementation-specific extension. Type casts bind
more tightly than addition, so "(void *)A+1" is parsed as "((void *)A)+1".
This is invalid according to the standard ("void" doesn't have a size, so
you can't perform arithmetic on a "void*").

Implementations which allow arithmetic on void* (e.g. gcc) act as if
sizeof(void)==1 in such cases. Because you convert before adding, both
expressions have the same value.

The reason why the original expressions had different values is that, in
pointer arithmetic, the offset is the number of items rather than the
number of bytes, so the calculation scales the offset by the size of the
type being pointed to.

So "A+1" is one int past A ("A" is a pointer to int) while "&A+1" is one
array of 3 ints past A ("&A" is a pointer to an array of 3 ints).

To correctly apply an explicit cast to your original code, you should have
written:

     printf("the address of A+1: %p\n", (void *)(A+1));     // 3'
     printf("the address of &A+1: %p\n", (void *)(&A+1));   // 4'

This will (typically) produce the same result as before, except that this
version doesn't rely upon implementation-specific behavior (i.e. all
pointers using the same representation).

[toc] | [prev] | [next] | [standalone]

#10286

Nobody <nobody@nowhere.com> 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) kst-u@mib.org  <http://www.ghoti.net/~kst>
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#10304

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

[toc] | [prev] | [next] | [standalone]

#10314

Stanley Rice <heconghui@gmail.com> 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.

[toc] | [prev] | [next] | [standalone]

#10316

On 09/15/2011 09:23 PM, Stanley Rice wrote:
> 
> <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.

No, because the same character strings that are printed out when you use
printf("%p", ...) must be readable by scanf("%p", ...), and the result
of the read must be a pointer that compares equal to the original. If
two pointers that pointed at different locations caused the same string
to be printed out, then when scanned back in, the would necessarily
compare equal not only to their originals, but also to each other, since
the printed strings provide no way to distinguish them. Pointers to
different locations in memory are not allowed to compare equal, so they
must print out different character strings.

Equal pointers can print differently (though it is unlikely that they
would do so); unequal pointers MUST print differently.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#10317

On Thu, 15 Sep 2011 10:28:10 -0700, Keith Thompson wrote:

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

Ah. I actually checked the spec regarding printf("%p"), which doesn't say
anything useful:

       p       The argument shall be a pointer to void.  The  value
               of  the  pointer  is  converted  to  a  sequence  of
               printable characters, in  an  implementation-defined
               manner.

It didn't occur to me to check scanf(), which says:

       p       Matches an implementation-defined set of  sequences,
               which  should  be  the  same as the set of sequences
               that may be produced by the  %p  conversion  of  the
               fprintf  function.  The corresponding argument shall
               be  a  pointer  to   a   pointer   to   void.    The
               interpretation  of the input item is implementation-
               defined.  If the input item  is  a  value  converted
               earlier  during  the  same  program  execution,  the
               pointer that results shall  compare  equal  to  that
               value;  otherwise  the behavior of the %p conversion
               is undefined.

Which suggests that the answer to the question:

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

should be "yes" (subject to the proviso that comparing the pointers for
equality is actually legal).

However: I suggest that it would be legal for the implementation to print
all pointers as "?" if it can detect that the *scanf() functions aren't
used by the program.

[toc] | [prev] | [next] | [standalone]

#10340

Nobody <nobody@nowhere.com> writes:
[...]
> However: I suggest that it would be legal for the implementation to print
> all pointers as "?" if it can detect that the *scanf() functions aren't
> used by the program.

Legal, yes.  Sane, no.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#10345

In article <ln7h588g0x.fsf@nuthaus.mib.org>,
Keith Thompson  <kst-u@mib.org> wrote:
>Nobody <nobody@nowhere.com> writes:
>[...]
>> However: I suggest that it would be legal for the implementation to print
>> all pointers as "?" if it can detect that the *scanf() functions aren't
>> used by the program.
>
>Legal, yes.  Sane, no.

That doesn't matter around here, does it?

-- 
One of the best lines I've heard lately:

    Obama could cure cancer tomorrow, and the Republicans would be
    complaining that he had ruined the pharmaceutical business.

(Heard on Stephanie Miller = but the sad thing is that there is an awful lot
of direct truth in it.  We've constructed an economy in which eliminating
cancer would be a horrible disaster.  There are many other such examples.)

[toc] | [prev] | [next] | [standalone]

#10541

Keith Thompson <ks...@mib.org> wrote:
> Nobody <nob...@nowhere.com> writes:
> > However: I suggest that it would be legal for the
> > implementation to print all pointers as "?" if it can
> > detect that the *scanf() functions aren't used by the
> > program.
>
> Legal, yes. ...

I disagree. Implementation-defined does not mean anything goes.
I don't think '?' for all pointers can be said to be the 'value
of the pointer converted to a sequence of printing characters.'

Would you say puts() is free to only ever output '?' since no
strictly conforming program can read it back from stdout?

--
Peter

[toc] | [prev] | [next] | [standalone]

#10548

Peter Nilsson <airia@acay.com.au> writes:
> Keith Thompson <ks...@mib.org> wrote:
>> Nobody <nob...@nowhere.com> writes:
>> > However: I suggest that it would be legal for the
>> > implementation to print all pointers as "?" if it can
>> > detect that the *scanf() functions aren't used by the
>> > program.
>>
>> Legal, yes. ...
>
> I disagree. Implementation-defined does not mean anything goes.
> I don't think '?' for all pointers can be said to be the 'value
> of the pointer converted to a sequence of printing characters.'
>
> Would you say puts() is free to only ever output '?' since no
> strictly conforming program can read it back from stdout?

I concede; always printing "?" would not be conforming, since it
does not meaningfully satisfy the requirement (vague though that
requirement is).

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#10283

On 09/15/2011 08:36 AM, Stanley Rice wrote:
...
> 1. when we use %p to print the pointer, but the argument is not
> explicitly converted, will it implicitly be converted to (void *)
> type?

No, and that's what makes the behavior undefined. That's because
printf() accepts a variable list of arguments. For the variable part of
it's argument list, the only implicit conversions that occur are the
default argument promotions.

> 2. Why the equal pointers will print differently? It's machine
> dependent or anything else? Can we say that, two pointers must be
> equal if they are printed the same.

As a general rule, what's printed by the printf("%p, ... ) is related to
the representation of a pointer. The standard does not require that
pointers pointing to the same location have the same representation,
only that they must compare equal. Real implementations have used
representations for which such a requirement would be a problem. I've
used machines where addresses were represented by a 16-bit segment and a
16-bit offset, and the physical address was 16*segment+offset, so that
there were a great many different ways of forming pointers with
different representations that point at the same location.

Yes, it is machine dependent. In principle, even different
implementations for the same machine could implement pointers
differently, but that's rather unlikely.

I believe that two pointers that print the same must compare equal; but
not vice-versa.

> 3. In my previous post. If I change my code:
>     printf("the address of A+1: %p\n", (void *)A+1);     // 3'
>     printf("the address of &A+1: %p\n", (void *)&A+1);   // 4'
> 
> statement 3' and 4' will print the same thing. Why it that compared to
> my original code, without explicitly cast.

(void*)A+1 is a constraint violation, because (void*)A is a pointer, and
is not a pointer to an object type. Many compilers operate, by default,
in a non-conforming mode that allows such expressions. They treat it as
the rough equivalent of (void*)((char*)A + 1). Since A and &A are
pointers of different types that point at the same location.
(void*)((char*)&A + 1) points at the same location a (void*)((char*)A +
1), which is why the results you got were the same.

If your compiler allows such code, find out if you can disable that
"feature". For instance, with gcc, use "-Wpointer-arith".  It represents
a fundamental misconception of what void* means to allow pointer
arithmetic on void*. Before the inventions of void*, char* was used for
the same purpose. void* was invented specifically to indicate that your
code is NOT keeping track of what type of thing the pointer points at.
It differs from char* in two important ways. The first way is that
pointers to other object types convert to and from void* implicitly,
which greatly simplifies typical uses of void*.

The second way, and the one that is relevant here, is that it is a
constraint violation to use a pointer to void in any context that
requires knowledge of the type of object that the pointer points at. In
particular, if p is a pointer to an object type, and n is an integer,
the value of p+n points at a location that is farther along in memory by
exactly enough space for n objects of the type that p points at. In
other words, (char*)(p+n) = (char*)p + n*sizeof *p. However, if p is a
pointer to void, there is NO type type p points at. sizeof *p and
sizeof(void) both constraint violations, as is p+n. If you don't want to
get diagnostic messages as a result of writing code like p+1, you should
make sure that p is a pointer to an object type, such as char*, not a
pointer to void.

[toc] | [prev] | [next] | [standalone]

#10278

On Sep 14, 9:41 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> Stanley Rice <hecong...@gmail.com> writes:
> > I am confused of array and pointer these days, and wrote some testing
> > program. one of the snippet is as below:
>
> > int A[3];
>
> > printf("%p\n", A);          //   1
> > printf("%p\n", &A);         //   2
> > printf("%p\n", A + 1);      //   3
> > printf("%p\n", &A + 1);     //   4
>
> > It shows that the result of first and second statement is the same,
> > while the result of statement 3 and statement 4 is different. I can
> > understand the difference of result 3 and result 4, as if the pointer
> > to arrays are of different levels. But why the statement 1 and
> > statement 2 generate the same result?
>
> Nit: convert the pointers to (void *) because that's what %p expects.
> If you do that, 1 and 2 will always produce the same result no matter
> what type the array has.  I've used a machine where they won't always be
> the same if the type of A is char[3].
>
> The differences and potential differences come from the fact that A and
> &A are different things.  When an array is used in most contexts, it is
> converted to a pointer to its first element.  Being the operand of the
> & operator is an exception to this rule.  So in case 1, A is an 'int *'
> and in case 2, &A is a pointer to the whole array (the type is
> 'int (*)[3]' if you are interested in the details).
>
> On most systems, a pointer to the start of an array and a pointer to the
> whole array will print the same using %p and they are guaranteed to be
> the same when converted to a common type.  I.e.
>
>   (void *)A == (void *)&A[0] && (void *)A == (void *)&A
>
> is always true.  The types are different and that means that they may
> have different representations so %p might print different things for
> in your unconverted printf calls (1 and 2).
>
> The difference in 3 and 4 is due to the "levels" as you put it.  Adding
> to a pointer adds the size of the thing pointed to.  A + 1 adds one to
> an int * producing a pointer to A[1].  In fact, A[n] is defined to be
> *(A + n).  &A + 1 produces a pointer that points just past the end of
> the array A.
>
> I thought this might be FAQ (http://c-faq.com/) but I could not find the
> right answer there .  Even so, read section 6 about arrays and pointers
> -- it's good stuff.
>
> > 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 ?

[toc] | [prev] | [next] | [standalone]

#10284

On 09/15/2011 08:22 AM, Stanley Rice wrote:
> On Sep 14, 9:41 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>> Stanley Rice <hecong...@gmail.com> 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.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c

csiph-web