🚀 go-pugleaf

Kurt Watzka <ua302aa@sun2.lrz-muenchen.de> wrote:
>Obviously, there are compilers that handle
> 
>   char *foo = "Hello world";
> 
>different form
> 
>   const char *bar = "Hello world";
> 
>as far as the placement of the string literal is concerned. String   
>literals are arrays of "const char". This implies that they can
>be placed in read only memory. Does the definition of "foo" somehow
>prevent this placement?

No.  The characters that make up the string are const, even if the
pointer doesn't agree.  It's undefined behaviour to try to modify any
of the characters.  (I get a SIGSEGV here.)

To look at it another way, the two definitions above could be
reimplemented as:

const char __foo[] = {'H','e','l','l','o',' ','w','o','r','l','d','\0'};
char *foo;
foo = (char *) __foo;

const char __bar[] = {'H','e','l','l','o',' ','w','o','r','l','d','\0'};
const char *bar;
bar = (const char *) __bar;

The casts, which in normal definitions are implicit, are the key to
this.  In the case of bar, the cast is a no-op, save for the decay of
an array to a pointer.  In the case of foo, the cast discards the
constness of the characters.  A good compiler ought to be able to warn
about this, but there's too much old code (that was written when const
wasn't available) for this to be a default on most compilers.

>In other words, what is wrong with the statement: "String literals
>are arrays of const char, and hence may be placed in a read only 
>region of storage, even if they are used to initialize a non const
>char *"?

It's so long that by the time one gets to the end of the statement one
has forgotten what the beginning was.  But it's accurate.

-zefram