Pointer Declaration/Array definition

[ur8x]

Why does this declaration give undefined result:

file1: extern char * p;
file2: char p[10];

Let's assume p has been initialized, now accessing p[i]...

[Ivan Vecerina]

<ur**@ur8x.co m> wrote in message
news:cg******** **@news-int2.gatech.edu ...
|
| Why does this declaration give undefined result:
|
| file1: extern char * p;
Allocates memory to store a pointer, which may later be changed
to refer to any memory location.
| file2: char p[10];
Allocates memory for 10 characters at a fixed address.
When the variable p is used, the array is implicitly
converted to a pointer to the first element of the array.
|
| Let's assume p has been initialized, now accessing p[i]...

What is supposed to happen if code that includes
file1 contains a statement such as:
p = NULL;
hth,
Ivan
--
http://ivan.vecerina.com/contact

[CBFalconer]

ur**@ur8x.com wrote:

Why does this declaration give undefined result:

file1: extern char * p;
file2: char p[10];

Let's assume p has been initialized, now accessing p[i]...

file1 thinks that p is a pointer to a char. file2 thinks that p
is an array of 10 chars. This is why the "extern char *p;" should
be in a header file that is included in both file1 and file2, and
then the compiler would complain. This follows the simple
principle that header files are used to export things other
modules need to know about.

--
fix (vb.): 1. to paper over, obscure, hide from public view; 2.
to work around, in a way that produces unintended consequences
that are worse than the original problem. Usage: "Windows ME
fixes many of the shortcomings of Windows 98 SE". - Hutchison

[Jens.Toerring]

ur**@ur8x.com wrote:

Why does this declaration give undefined result: file1: extern char * p;
file2: char p[10];

Other people already explained why this won't work, i.e. because
a char array and a char pointer are very different things, having
not much in common. I guess your confusion is coming from the
fact that under certain conditions the name of an array is dealt
with as if it would be a pointer to (the first element of) the
array, e.g. in

char p[ ] = "hello word";
char *pp = p;

But this only happens when the array is used in "value context",
i.e. if it is used as if it had a value. Then, and only then, it
is taken to mean (often called "it decays into") the address of
the first element of the array.

But in

extern char *p;

'p' isn't used in "value context" (the compiler even doesn't know
that somewhere else an array of chars named 'p' was defined since
that's in a different source file), so the "decay to pointer" rule
doesn't get involved.
Regards, Jens
--
\ Jens Thoms Toerring ___ Je***********@p hysik.fu-berlin.de
\______________ ____________ http://www.toerring.de

[ur8x]

Ivan Vecerina <to************ ***********@vec erina.com> wrote:

<ur**@ur8x.co m> wrote in message
news:cg******** **@news-int2.gatech.edu ...
|
| Why does this declaration give undefined result:
|
| file1: extern char * p;
Allocates memory to store a pointer, which may later be changed
to refer to any memory location.
| file2: char p[10];
Allocates memory for 10 characters at a fixed address.
When the variable p is used, the array is implicitly
converted to a pointer to the first element of the array.
|
| Let's assume p has been initialized, now accessing p[i]...
Yes, well if p is NULL, accessing p[i] wouldn't make sense.
But let's say p[] has been initialized, if the array is
implicitly converted to a point to the first element, shouldn't
pointer arithmetic get us to p + i * sizeof(char)?
What is supposed to happen if code that includes
file1 contains a statement such as:
p = NULL;
hth,
Ivan
--
http://ivan.vecerina.com/contact

[ur8x]

Ok, here is what I want to know: What exactly happens when
p[i] is called, as far accessing and dereferncing that makes
the code wrong (yes, I know it should not work, I just want
to know why).

Thanks.
Je***********@p hysik.fu-berlin.de wrote:

ur**@ur8x.com wrote:

Why does this declaration give undefined result: file1: extern char * p;
file2: char p[10];

Other people already explained why this won't work, i.e. because
a char array and a char pointer are very different things, having
not much in common. I guess your confusion is coming from the
fact that under certain conditions the name of an array is dealt
with as if it would be a pointer to (the first element of) the
array, e.g. in char p[ ] = "hello word";
char *pp = p; But this only happens when the array is used in "value context",
i.e. if it is used as if it had a value. Then, and only then, it
is taken to mean (often called "it decays into") the address of
the first element of the array. But in extern char *p; 'p' isn't used in "value context" (the compiler even doesn't know
that somewhere else an array of chars named 'p' was defined since
that's in a different source file), so the "decay to pointer" rule
doesn't get involved.
Regards, Jens
--
\ Jens Thoms Toerring ___ Je***********@p hysik.fu-berlin.de
\______________ ____________ http://www.toerring.de

[Jens.Toerring]

ur**@ur8x.com wrote:

Je***********@p hysik.fu-berlin.de wrote:
Please be so kind not to top-post.
Ok, here is what I want to know: What exactly happens when
p[i] is called, as far accessing and dereferncing that makes
the code wrong (yes, I know it should not work, I just want
to know why).

In the process of compiling and linking the symbol 'p' will
get replaced by a certain memory address. The code in file2
knows that at this address there's a string, e.g. "ABCDEFG".
But the code in file1 assumes that at that address a pointer
to char is stored. Since you have "ABCDEFG" at that address
the code in file1 will interpret this value stored there as
an address like 0x61626364' (assuming you have 4 byte char
wide addresses on a big-endian machine and ASCII charset, so
0x61 == 'A' etc.). But that's of course no address but just
the bit pattern of the start of the string. If you then use
'p[i]' it tries to dereference that address (0x61626364 + i),
an address to which you proably have no access to and thus
you get a segmentation fault.
Regards, Jens
--
\ Jens Thoms Toerring ___ Je***********@p hysik.fu-berlin.de
\______________ ____________ http://www.toerring.de

[Ivan Vecerina]

<ur**@ur8x.co m> wrote in message
news:cg******** **@news-int.gatech.edu. ..
| Ivan Vecerina <to************ ***********@vec erina.com> wrote:
| > <ur**@ur8x.co m> wrote in message
| > news:cg******** **@news-int2.gatech.edu ...
| > |
| > | Why does this declaration give undefined result:
| > |
| > | file1: extern char * p;
| > Allocates memory to store a pointer, which may later be changed
| > to refer to any memory location.

| > | file2: char p[10];
| > Allocates memory for 10 characters at a fixed address.
| > When the variable p is used, the array is implicitly
| > converted to a pointer to the first element of the array.
| > |
| > | Let's assume p has been initialized, now accessing p[i]...
|
| Yes, well if p is NULL, accessing p[i] wouldn't make sense.
| But let's say p[] has been initialized, if the array is
| implicitly converted to a point to the first element, shouldn't
| pointer arithmetic get us to p + i * sizeof(char)?

This "implicit conversion" is performed by the compiler, when
it knows that an array is being used as if it were a pointer.
But the generated code and memory layout is very different.

For the array, the assembly pseudocode for p[1] looks like:
- if p is an array:
1) load the address of p in register A
2) increment register A
3) read the byte at address A
- if p is a pointer:
1) load the address of p in register A
2) load the pointer at address A into register B
3) increment register B
4) read the byte at address B

The memory layout is what my previous comments where trying
to explain (left quoted above).
--
http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form
Brainbench MVP for C++ <> http://www.brainbench.com

[ur8x]

> get replaced by a certain memory address. The code in file2

knows that at this address there's a string, e.g. "ABCDEFG".
But the code in file1 assumes that at that address a pointer
to char is stored. Since you have "ABCDEFG" at that address
the code in file1 will interpret this value stored there as
an address like 0x61626364' (assuming you have 4 byte char
wide addresses on a big-endian machine and ASCII charset, so
0x61 == 'A' etc.). But that's of course no address but just
the bit pattern of the start of the string. If you then use
'p[i]' it tries to dereference that address (0x61626364 + i),
an address to which you proably have no access to and thus
you get a segmentation fault.

Excellent, so the p[i] is treated as if it holding an address
to the actual data intended to be read. Thanks.

P.S. Sorry about the top-posting, I just switched my default
editor to emacs.

[ur8x]

Ivan Vecerina <to************ ***********@vec erina.com> wrote:

This "implicit conversion" is performed by the compiler, when
it knows that an array is being used as if it were a pointer.
But the generated code and memory layout is very different. For the array, the assembly pseudocode for p[1] looks like:
- if p is an array:
1) load the address of p in register A
2) increment register A
3) read the byte at address A
- if p is a pointer:
1) load the address of p in register A
2) load the pointer at address A into register B
3) increment register B
4) read the byte at address B The memory layout is what my previous comments where trying
to explain (left quoted above).

Thanks. Referring to some other posts, does this "implicit
conversion" also known as "decaying convention?"