Difference between declaring a string using array and pointer notation

Printable View

11-06-2005
hzmonte

Difference between declaring a string using array and pointer notation

Despite the claim that the array notation is nothing more than a thinly disguised form of pointer notation, I have just found out that there is at least a difference, which has taken me half a day to discover:
[quote]
(http://www.scit.wlv.ac.uk/cbook/chap6.strings.html)
There is an interesting and important difference between the following declarations which may seem equivalent.
char msg[] = "Hello";
and
char *msg = "Hello";
The first declaration reserves an aggregate of 6 characters in the memory space currently being allocated, the data space is initialised to the relevant set of character values. This is only initialisation, the values and hence the text of the string can be altered.
The second declaration reserves enough space to hold a pointer to a character, this pointer is initialised to point to a "secret" system place within your program where the actual character string "Hello" is stored. This is likely to be the same general place that is used for storing layout specification strings used by the printf() and scanf() functions. The value stored in "msg", which is only a pointer to a character, can be altered so it points to a different character. However, and this is encouraged by the ANSI standard, the actual string constant should not be alterable, although this restriction is seldom enforced.
[unquote]
Indeed, under gcc, changing a string declared using the second method produces a compilation warning, and running the executable produces a segmentation fault.
1. Are there any other differences?
2. What is the underlying reasoning behind this difference?

Also, if I have
const char msg[] = "xxxxxx";
and
char *p = msg;
I can change msg by *(p+1)='y' for example even though msg is declared as const. At least, gcc does not give a warning.
3. Is there a name for this problem? (i.e. something like alias problem, though I am under the impresion that alias analysis is related to code parallelization.)
4. Is it possible that a good compiler detects this?
11-06-2005
xeddiex

No offence but most of us know that already dude. Nothing new.

Here's something to keep ya more busy: But I heard that char a[] was identical to char *a

And here's More

[sidenote: what you're now runing into about arrays and pointers sopposively being the same, thus, you can modify a "string literal" bit me in the arse once too when I first started learning C. I was like What?!.. you can't do that? Aww man!.. that sucks!]
11-06-2005
hzmonte

thanks

Quote:

Originally Posted by xeddiex

No offence but most of us know that already dude. Nothing new.

Well, at least I have done my homework.
And none of my 2 C books mention it. Nor the C Tutorial in this web site.
11-06-2005
Ancient Dragon

Quote:

Originally Posted by hzmonte

4. Is it possible that a good compiler detects this?

c++ compilers will produce errors when attempting to assign an non-const pointer to a const object.
11-06-2005
Harbinger

> (http://www.scit.wlv.ac.uk/cbook/chap6.strings.html)
Any tutorial which sites IOCCC as being a good place to study C, and which routinely uses gets() for all input deserves a good shunning.

Statements like this "This is possible because C++ is a strict superset of C" are absolutely wrong.

Code:

int main ( ) { int new = 0; return new; }

Is perfectly valid C which will make any C++ compiler throw a fit.

Quote:

An aggregate to hold the image of a character screen could be declared in the following fashion
char screen[25][80];
This clearly reflects a structure of 25 rows of 80 characters. Interestingly the complete image could be sent to the screen by code like
while(i<2000) sendchar(*(*screen+i++));
To understand this it is useful to think of "screen" as a variable of type pointer-to-pointer-to-char so the expression *screen is of type pointer-to-char, the addition of i++ to this value generates the address of a character and the "outer" asterisk operator

I can see where you're being confused - the author doesn't know the difference between arrays and pointers either.

> 4. Is it possible that a good compiler detects this?
gcc -W -Wall -ansi -pedantic -O2 foo.c
foo.c: In function ‘main’:
foo.c:4: warning: initialization discards qualifiers from pointer target type
Sure, learn to use the one you've got.
11-06-2005
hzmonte

Quote:

Originally Posted by xeddiex

Here's something to keep ya more busy: But I heard that char a[] was identical to char *a

And here's More

[sidenote: what you're now runing into about arrays and pointers sopposively being the same, thus, you can modify a "string literal" bit me in the arse once too when I first started learning C. I was like What?!.. you can't do that? Aww man!.. that sucks!]

But the first link does not clearly say the pointer notation assigns memory in the system area resulting in the inability to change the string.
Q6.3 from the second link mentions that one of the exceptions to the equivalence of arrays and pointers is "a string literal initializer for a character array" but does not elaborate. I guess one has to look at the References below.
My last 2 questions are not just about the equivalence of arrays and pointers. It is more about a _const_ array being modifiable by a pointer.
11-06-2005
hzmonte

Quote:

Originally Posted by Harbinger

> (http://www.scit.wlv.ac.uk/cbook/chap6.strings.html)
Any tutorial which cites IOCCC [International Obfuscated C Code Contest] as being a good place to study C, and which routinely uses gets() for all input deserves a good shunning.

But is the info in http://www.scit.wlv.ac.uk/cbook/chap6.strings.html basically correct?
11-06-2005
Prelude

>Despite the claim that the array notation is nothing more than a thinly disguised form of pointer notation
Arrays are not pointers, and pointers are not arrays. Everyone who can claim proficiency in C knows this.

>1. Are there any other differences?
No, that's really the big one. Initializing an array of char with a string literal copies the contents of the string literal to the array. Initializing a pointer to char with a string literal copies the address of the string literal (which might be in read-only memory) to the pointer.

>2. What is the underlying reasoning behind this difference?
I think it's very intuitive, seeing as how pointers and arrays are completely different types and the rule you've discovered makes perfect sense for each of them. It just happens that most of the time when using an array, it's converted to a pointer to the first element. That doesn't change the fact that an array isn't actually a pointer.

>3. Is there a name for this problem?
I don't think there's a medical term for stupidity. Your example intentionally tries to break the type system by sidestepping a const qualified type with a non-const qualified alias.

>4. Is it possible that a good compiler detects this?
Sure. It's not too difficult either, so if you turn your warnings up you'll probably be informed of assigning a const qualified type to a non-const qualified pointer.

>arrays and pointers sopposively being the same, thus, you can
>modify a "string literal" bit me in the arse once too
Modifying a string literal has nothing to do with arrays and pointers supposedly being the same. A string literal has an array type, not a pointer type. The reason you can't modify a string literal is because the C standard doesn't specify whether string literals with identical contents are distinct or not, or whether string literals are stored in read-only memory. Both of those are desirable optimizations, and both cause subtle and annoying problems if you modify the contents. ;)

>And none of my 2 C books mention it. Nor the C Tutorial in this web site.
Technically the tutorial on this site is C++, but it's far from complete (or even good). I don't know what two books you have, but for the most part the relationship between arrays and pointers is treated as an advanced topic. I think that's a shame, but I can see their point.

>But the first link does not clearly say the pointer notation assigns
>memory in the system area resulting in the inability to change the string.
That's because it might not. The compiler isn't required to do so, but it is allowed to do so, which is why modifying string literals is discouraged.

>But is the info in http://www.scit.wlv.ac.uk/cbook/chap6.strings.html basically correct?
Well, it's not blatantly wrong (only looking at that page), but I don't like this part: "although this restriction is seldom enforced". Of course it's not enforced, because there's nothing to enforce. Modifying a string literal that's in read-only memory is undefined behavior and undefined behavior is a lack of restrictions. The compiler is free to do whatever it pleases.
11-06-2005
hzmonte

Quote:

Originally Posted by Prelude

>And none of my 2 C books mention it. Nor the C Tutorial in this web site.
Technically the tutorial on this site is C++, but it's far from complete (or even good). I don't know what two books you have, but for the most part the relationship between arrays and pointers is treated as an advanced topic. I think that's a shame, but I can see their point.

Dear Prelude, how about writing a piece in the "What's the difference between ..." section in this website's Programming FAQ?
And does this difference also valid in C++?
11-06-2005
cwr

Quote:

Originally Posted by hzmonte

But the first link does not clearly say the pointer notation assigns memory in the system area resulting in the inability to change the string.

No, but see http://www.eskimo.com/~scs/C-faq/q1.32.html from the same site.

You should read the whole of the comp.lang.c FAQ and the whole of the C board FAQ. There is not much point in people making additions to the C board FAQ, as you suggested above, if the material is already covered well in the comp.lang.c FAQ.

It is a shame that the C board FAQ does not link to the comp.lang.c FAQ, since much material is covered there that is not covered here. They should complement each other.
11-06-2005
Dave_Sinkula

Quote:

Originally Posted by cwr

It is a shame that the C board FAQ does not link to the comp.lang.c FAQ, since much material is covered there that is not covered here.

It is, sorta, it's just not easy to find:
http://www.cprogramming.com/cgi-bin/...ategory&CID=47