buffer and &buffer 
Author Message
 buffer and &buffer

Hi!

Suppose I created an array named "buffer". Do you know why "buffer" and
"&buffer" return the same number?

I *do* expect "buffer" to return the offset of the array in memory, but I
don't know why "&buffer" returns the memory address, too...

Here's the code:

--- cute here ---

#include <stdio.h>
#include <conio.h>
int main(int argc,char *argv[]){
        char buffer[10];
        clrscr();
        printf("\n\nbuffer: %p\n&buffer: %p\n\n", buffer, &buffer);
        return(0);

Quote:
}

--- cut here ---

Kind regards,

Fernando Ariel Gont

[To send a personal reply, please remove the NOSPAM tag]
--



Fri, 07 Feb 2003 03:00:00 GMT  
 buffer and &buffer
Would logic dictate it the other way around? & is the standard syntax for
'address of' I thought. As in: *foo = &bar;

-- Matt Lesko

Quote:

> Hi!

> Suppose I created an array named "buffer". Do you know why "buffer" and
> "&buffer" return the same number?

> I *do* expect "buffer" to return the offset of the array in memory, but I
> don't know why "&buffer" returns the memory address, too...

> Here's the code:

> --- cute here ---

> #include <stdio.h>
> #include <conio.h>
> int main(int argc,char *argv[]){
>         char buffer[10];
>         clrscr();
>         printf("\n\nbuffer: %p\n&buffer: %p\n\n", buffer, &buffer);
>         return(0);
> }

> --- cut here ---

> Kind regards,

> Fernando Ariel Gont

> [To send a personal reply, please remove the NOSPAM tag]
> --


--



Sun, 09 Feb 2003 08:38:13 GMT  
 buffer and &buffer


Quote:
>I *do* expect "buffer" to return the offset of the array in memory, but I don't
>know why "&buffer" returns the memory address, too...

Well what did you expect it to return? The language has always the two
as the same as long as buffer is the 'name' of an array or function. Of
course it is different if buffer is the name of a pointer.

Francis Glassborow      Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
--



Sun, 09 Feb 2003 08:38:20 GMT  
 buffer and &buffer

Quote:

> I *do* expect "buffer" to return the offset of the array in memory, but I
> don't know why "&buffer" returns the memory address, too...

"buffer" is, in most contexts, the address of the *first element*
of the array.  "&buffer" is the address of the whole array.  Since
these coincide, of course they have the same numerical value.
--



Sun, 09 Feb 2003 08:38:38 GMT  
 buffer and &buffer

Quote:
>Suppose I created an array named "buffer". Do you know why "buffer" and
>"&buffer" return the same number?

In expressions, buffer decays into a pointer to the first char of the
array, while &buffer is a pointer to the full array.  For obvious
reasons, the two pointers must point to the same memory address.

Quote:
>I *do* expect "buffer" to return the offset of the array in memory, but I
>don't know why "&buffer" returns the memory address, too...

What would you expect &buffer to "return"?

Quote:
>#include <stdio.h>
>#include <conio.h>            <-- no such thing in C
>int main(int argc,char *argv[]){
>    char buffer[10];
>    clrscr();               <-- no such thing in C
>    printf("\n\nbuffer: %p\n&buffer: %p\n\n", buffer, &buffer);

This is downright wrong!  %p expects a void pointer, not *any* type of
pointer.

Dan
--
Dan Pop
CERN, IT Division

Mail:  CERN - IT, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland
--



Sun, 09 Feb 2003 08:39:28 GMT  
 buffer and &buffer


Quote:
> Suppose I created an array named "buffer". Do you know why "buffer" and
> "&buffer" return the same number?

Umm, you shouldn't be saying &buffer when buffer is declared as an array.
The reason is that when you write the array declaration, the compiler
reserves space for the contents of the array.  That's it.  When you say
&buffer, you are asking for the *memory address* of the pointer to the
buffer.  Well that doesn't always exist in memory, so there is no pointer.
It's just implicit in the compiled code.  Eg,

Quote:
> #include <stdio.h>
> #include <conio.h>
> int main(int argc,char *argv[]){
> char buffer[10];
> clrscr();
> printf("\n\nbuffer: %p\n&buffer: %p\n\n", buffer, &buffer);
> return(0);
> }

char buffer[10] declares a sequence of 10 bytes on the stack.  The pointer
is at a fixed offset to the stack pointer (or base pointer, depending on
calling conventions, processor, etc).  That knowledge is directly embedded
into the compiled app byu generating code such as (maybe, on x86/Intel): MOV
AL, BYTE PTR [EBP - 5]

What do you expect to get in &buffer in this case?  It doesn't exist.

I find it strange that you are getting an actual result at all!  I'd expect
the compiler to throw a temper tantrum when you write that.

Someone correct me if I'm wrong.

Chris Smith
--



Sun, 09 Feb 2003 08:39:34 GMT  
 buffer and &buffer

wrote in comp.lang.c.moderated:

Quote:
> Hi!

> Suppose I created an array named "buffer". Do you know why "buffer" and
> "&buffer" return the same number?

> I *do* expect "buffer" to return the offset of the array in memory, but I
> don't know why "&buffer" returns the memory address, too...

> Here's the code:

> --- cute here ---

> #include <stdio.h>
> #include <conio.h>

Non standard header.

Quote:
> int main(int argc,char *argv[]){
>    char buffer[10];
>    clrscr();

Non standard function.

Quote:
>    printf("\n\nbuffer: %p\n&buffer: %p\n\n", buffer, &buffer);

Undefined behavior for the second pointer parameter, maybe for the
first.  Always, ALWAYS cast to (void *) when passing pointers to
printf() with the "%p" conversion specifier.

Quote:
>    return(0);
> }

The name of an array decays into a pointer to its first element when
passed as a parameter to a function call.  You can use & with the name
of an array, as you did here.  The result is a pointer to the same
memory location, but the type of the pointer is "pointer to array of
chars", not pointer to char.  There is no guarantee that the two will
have the same representation even though they point to the same
address.

Jack Klein
--
Home: http://jackklein.home.att.net
--



Sun, 09 Feb 2003 08:39:47 GMT  
 buffer and &buffer

Quote:
> Suppose I created an array named "buffer". Do you know why "buffer" and
> "&buffer" return the same number?
[...]
>    char buffer[10];

"buffer" is the address of the first element of buffer, and has type
char *.  "&buffer" is the address of the entire array, and has type
char (*)[10].  Because the first element is at the beginning of the
array, the pointers are equal (when converted to the same type).
buffer+1 and &buffer+1 are different, though.
--



Sun, 09 Feb 2003 08:39:36 GMT  
 buffer and &buffer

[Slightly rearranged]

Quote:
> Suppose I created an array named "buffer". Do you know why "buffer" and
> "&buffer" return the same number?

> #include <stdio.h>
> #include <conio.h>
> int main(int argc,char *argv[]){
>    char buffer[10];
>    clrscr();
>    printf("\n\nbuffer: %p\n&buffer: %p\n\n", buffer, &buffer);
>    return(0);
> }

> I *do* expect "buffer" to return the offset of the array in memory, but I
> don't know why "&buffer" returns the memory address, too...

What else did you expect it to be? When you refer to an array, it decays
(in many contexts, including this one) to a pointer to the first element
of the array. This is (because arrays are contiguous in memory) in the
same location as the array itself. Of course, the _type_ is different;
in your case, the pointer resulting from the decay of buffer has type
pointer to char, whereas &buffer has type pointer to array of ten chars.

You might want to know, btw, that for complete compliance with the
standard, you should cast your pointers to void * if you pass them to
printf("%p"). You _may_ be able to get away with char *, but AFAICT the
gurus do not completely agree over that one, so it's probably wiser not
to.
Oh, and of course <conio.h> and clrscr() are off-topic here, but they're
immaterial to the actual problem. You don't need them here at all,
though, so it surprises me that you use them.

Richard
--



Sun, 09 Feb 2003 08:39:58 GMT  
 buffer and &buffer

Quote:
> Hi!
> Suppose I created an array named "buffer". Do you know why "buffer" and
> "&buffer" return the same number?
> I *do* expect "buffer" to return the offset of the array in memory, but I
> don't know why "&buffer" returns the memory address, too...

Well, let me reverse the question: what *else*, if not the storage
address of the array, could 'buffer' possibly mean?

The actual miracle is in that 'buffer' is auto-converted into
'&(buffer[0])' in many usages, not in that '&buffer' does what it
says.

But *not* in all of them.  sizeof(buffer), e.g., yields a totally
different result than sizeof(&buffer), in almost every case.

Also note the the two pointers you get from &buffer and buffer (both
assumed to be used 'in a pointer context) are of _different_ types.
One is a pointer to an array, the other a pointer to one element.
--

Even if all the snow were burnt, ashes would remain.
--



Sun, 09 Feb 2003 08:40:03 GMT  
 buffer and &buffer

Quote:


>>I *do* expect "buffer" to return the offset of the array in memory, but I don't
>>know why "&buffer" returns the memory address, too...

>Well what did you expect it to return? The language has always the two
>as the same as long as buffer is the 'name' of an array or function.

Nope, in the case of an array, the two have different types.

Dan
--
Dan Pop
CERN, IT Division

Mail:  CERN - IT, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland
--



Sun, 09 Feb 2003 03:00:00 GMT  
 buffer and &buffer

Quote:
>What do you expect to get in &buffer in this case?  It doesn't exist.

???  If the buffer object does exist, then it must be stored somewhere
in memory, right?  So, the & (address of) operator, can be used to
obtain its address.

Quote:
>I find it strange that you are getting an actual result at all!  I'd expect
>the compiler to throw a temper tantrum when you write that.

Why?  It's perfectly good code!

Quote:
>Someone correct me if I'm wrong.

You're dead wrong.  The FAQ might enlighten you.

Dan
--
Dan Pop
CERN, IT Division

Mail:  CERN - IT, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland
--



Sun, 09 Feb 2003 03:00:00 GMT  
 buffer and &buffer


Quote:


>> Suppose I created an array named "buffer". Do you know why "buffer" and
>> "&buffer" return the same number?

>Umm, you shouldn't be saying &buffer when buffer is declared as an array.
>The reason is that when you write the array declaration, the compiler
>reserves space for the contents of the array.  That's it.  When you say
>&buffer, you are asking for the *memory address* of the pointer to the
>buffer.  Well that doesn't always exist in memory, so there is no pointer.
>It's just implicit in the compiled code.  Eg,

>> #include <stdio.h>
>> #include <conio.h>
>> int main(int argc,char *argv[]){
>> char buffer[10];
>> clrscr();
>> printf("\n\nbuffer: %p\n&buffer: %p\n\n", buffer, &buffer);
>> return(0);
>> }

>char buffer[10] declares a sequence of 10 bytes on the stack.  The pointer
>is at a fixed offset to the stack pointer (or base pointer, depending on
>calling conventions, processor, etc).  That knowledge is directly embedded
>into the compiled app byu generating code such as (maybe, on x86/Intel): MOV
>AL, BYTE PTR [EBP - 5]

>What do you expect to get in &buffer in this case?  It doesn't exist.

>I find it strange that you are getting an actual result at all!  I'd expect
>the compiler to throw a temper tantrum when you write that.

>Someone correct me if I'm wrong.

&buffer is legal, though not here since, as others have pointed
out, the %p requires a void*.  An array is an lvalue and one may
take its address.  &buffer is a pointer to the array.  It points
to the same address as buffer (converted to a pointer), but has a
different type.  &buffer has type char(*)[10], a pointer to an
array of 10 characters.
--



Sun, 09 Feb 2003 03:00:00 GMT  
 buffer and &buffer


Quote:
>Suppose I created an array named "buffer". Do you know why "buffer" and
>"&buffer" return the same number?

They return *addresses*, not numbers.  If you *convert* the two
addresses to numbers, and print those, you may or may not get the
same result (this is up to the implementation).  Your system may
or may not actually implement addresses using raw numbers, and the
conversion from address to number may or may not use those raw
numbers in that case (the "spirit of C" suggests that it should,
but there is no hard-and-fast requirement).

A picture may also be helpful here.  Suppose "a" has type "array 4
of char":

        char a[] = "abc";

In memory, we have:

           +------+------+------+------+
        a: | 'a'  | 'b'  | 'c'  | '\0' |
           +------+------+------+------+

The value "&a[0]" (which is also the "value" of the array "a", due
to The Rule by which an array is converted to a pointer in many
contexts) might be drawn as an arrow pointing to a circle or box
around the letter "a":

            &a[0]
              |
              v
             ____
            /    \
           +------+------+------+------+
        a: | 'a'  | 'b'  | 'c'  | '\0' |
           +------+------+------+------+
            \____/

If you add 1 to this, you move along to the next letter, 'b'; add
another 1 and you move on to 'c', and so forth.

On the other hand, the value of &a -- the address of the entire
array -- should be drawn rather differently:

                        &a
                         |
                         v
             _________________________
            /                         \
           +------+------+------+------+
        a: | 'a'  | 'b'  | 'c'  | '\0' |
           +------+------+------+------+
            \_________________________/

If you add 1 to this, you move along by one entire array: (&a)+1
points just past the end of the array "a".

In other words, "&a" points to a really *big* box holding the entire
array, while "value-of-a", aka "&a[0]", points to a tiny little box
holding the first element of the array.

That is the difference between a pointer to an entire array, and
a pointer to its first element.  Using the pointer to the element,
and simply walking along "down the memory", as it were (down memory
lane?), you can find the entire array.  Using the pointer to the
entire array, you need not do any walking -- you can find the whole
thing all at once.  Whole arrays are slippery, though: they undergo
the transformation dictated by The Rule, and become pointers to
their first elements, the moment you try to do almost (but not
quite) anything.
--
In-Real-Life: Chris Torek, Berkeley Software Design Inc


--



Sun, 09 Feb 2003 03:00:00 GMT  
 buffer and &buffer

Quote:

> Suppose I created an array named "buffer". Do you know why "buffer"
> and
> "&buffer" return the same number?

The value is not very relevant; they have different _types_.  If buffer
is an array, the buffer means &buffer[0], the address of the first
element.  &buffer, on the other hand, means a pointer to the whole
array.  You'd declare them like this:

    T a[N]; /* a is an array with size N of type T */

    T *p = a; /* &a[0] */
    T (*pa)[N] = &a;

--

 __ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE
/  \ They love too much that die for love.
\__/ (an English proverb)
    Interstelen / http://www.interstelen.com/
 A multiplayer, strategic, turn-based Web game on an interstellar scale.
--



Sun, 09 Feb 2003 03:00:00 GMT  
 
 [ 31 post ]  Go to page: [1] [2] [3]

 Relevant Pages 

1. &buffer == buffer??

2. Why does stdio buffers preceed iostream buffers ??? (console)

3. SVGA & Linear frame buffer

4. AVIOpenFile & Flush Buffer

5. File buffering (setvbuf & other memory mapping)

6. fread() w/wo setvbuf() & buffering question

7. AVIOpenFile & Flush Buffer

8. ReadFile(), Win Modem & Buffer Issues

9. Threads & Shared buffer

10. How can I copy an unmannaged buffer to a managed buffer?

11. METHOD_BUFFERED not copying intermediate buffer to output buffer, why?

12. Parse a buffer : Make lex read a buffer rather than a file ?

 

 
Powered by phpBB® Forum Software