Thread: Assigning a pointer to a string literal - undefined behavior?

In another forum, this example code fragment was stated as being an example of undefined behavior. My understanding is that a literal string exists from program start to program termination, so I don't see the issue, even though the literal string is probably in a different part of memory.

Code:

/* ... */
    const char *pstr = "example";
/* or even */
    char *pstr = "example";
/* as long as no attempt is made to modify the data pointed to by pstr, */
/* unless pstr is later changed to point to a stack or heap based string */

It's undefined because a string literal is "const char*", and maybe stored in read-only memory.
You see:

Code:

char *pstr = "example";

is different to:

Code:

char pstr[] = "example";

The latter puts "example" string in the new, modifiable array "pstr", while the former is a mere pointer to the original literal string.

The code you've shown doesn't have undefined behaviour (although the definition of pstr on line 4 is an anachronism).

Any code that attempts to modify the data pointed to by pstr (assuming the definition on line 4) such as

Code:

   pstr[0] = '1';

will result in undefined behaviour for the reasons that GReaper mentioned.

The definition on line 2 is fine. Any attempt to modify the data pointed to by that version of pstr will result in a compilation error. Which is actually what you want if you try to modify that data.

In the future, please point/link us to whatever external references you mention (i.e. the other forum).
EDIT: Upon first reading, I thought I would need more context. Turns out I didn't, but more info/context rarely hurts.

Technically, those are not assignments, but initializations (since you declare the variable and give it an initial value in one line). On their own, neither of those statements results in undefined behavior.

This should give you a good idea: Question 1.32

Originally Posted by Barney McGrew

The string literal "example" is a 'char[8]', not a 'const char *'.

It really makes you wonder why they didn't define it as const and be done with it...

Originally Posted by GReaper

It really makes you wonder why they didn't define it as const and be done with it...

The reason is historical. Early versions of C did not support the concept of "const" (or the const keyword for that matter). Then, because of lobbying by lazy programmers, a rule was added which made the construct

Code:

    char *p = "Hello";
     /*   pointer operations on p */

valid as an alternative to

Code:

    char pstr[] = "Hello";
    char *p = pstr;
     /*   pointer operations on p which are invalid on pstr */

When the const keyword was eventually introduced (formally in the 1989 C standard, but there were some earlier compilers that supported it as an extension) there was enough legacy code reliant on this feature that removing it was not considered an option.

The standardisation committee can only add or remove features like this based on a vote. The removal of this feature has yet to come up as enough of a priority to be voted on (let alone have enough people involved willing to vote it out, since a LOT of clients of members on the committee have large code bases relying on this feature, and will apply pressure to keep it).


Such is the politics of standardisation. Bear in mind the old saying "A camel is a horse designed by committee".

I agree with your conclusion rcgldr.

There's an even clearer bit in the C11 draft standard (might well appear in earlier versions too):

6.7.9 Initialization
...
32
EXAMPLE 8
Committee Draft — April 12, 2011
N1570
The declaration

Code:

char s[] = "abc", t[3] = "abc";

defines ‘‘plain’’ char array objects s and t whose elements are initialized with character string literals.
This declaration is identical to

Code:

char s[] = { 'a', 'b', 'c', '\0' },
t[] = { 'a', 'b', 'c' };

The contents of the arrays are modifiable. On the other hand, the declaration

Code:

char *p = "abc";

defines p with type ‘‘pointer to char’’ and initializes it to point to an object with type ‘‘array of char’’
with length 4 whose elements are initialized with a character string literal. If an attempt is made to use p to
modify the contents of the array, the behavior is undefined.

There's nothing illegal about either statement in your original post. The second is bad because a compiler might let you try to modify it, whereas it should stop you if you do const char*. It's fairly common to see the latter even in new code, for a number of possible reasons:

• Perhaps because people get confused between const * char s (constant pointer, modifiable chars) and const char *c (modifiable pointer, constant chars) and decide not to confuse themselves.
• More likely because people really learn a language by using it, and you're never forced to use const out of necessity.
• Whenever const is taught, it's nearly invariably followed by explaining that you can modify a const through a non-const pointer. Which leaves the programmer thinking "const isn't very useful".
• Laziness.
• Using char* to create modifiable strings on a compiler where it's explicitly legal or just happens to work (e.g. z/VM V6R2.0 Information Center (April 2012)) and old gcc -fwriteable-strings, removed from gcc 4). This is a Bad Thing - why not just use a legal method instead...

Be careful about thinking that an unmodifiable constant is "in ROM" thinking of "ROM" as a type of memory. It might be. More likely under on OS is that it's in RAM but marked as not writable, and the OS will kill the program if it tries (e.g. segfault). Or it could be in modifiable RAM, but merged with another string. E.g. "there" could point to halfway through "hello there", so if you modified one you'd modify the other. It could permanently corrupt the data section of the executable.

Originally Posted by smokeyangel

• perhaps because people get confused between const * char s (constant pointer, modifiable chars) and const char *c (modifiable pointer, constant chars) and decide not to confuse themselves.

You mean between char * const s and const char *c (or, equivalently, char const *c).