Read-only functionality without 'const'

[karthikbalaguru]

Hi,

While trying to understand the difference between the following 2
methods, i have some interesting queries.
Method 1) char *s = "Hello";
and
Method 2) char s[] = "Hello";

How does the string 'hello' in first method lie in read-only memory
and the string 'hello' in second method lie in a modifiable memory ?
Only 'const' provides the 'Read-only' functionality in C . How come
this "char *s" provides that functionality ? What is the internal of
this functionality actually ?

The following is the snapshot of the info that has prompted me to
raise this query :-
In any context, char *s = "Hello"; just means that the pointer s is
assigned the address of the string literal "Hello". Normally, that
string literal will reside in read-only memory which means that it's
not legal to do:
char *s = "Hello"; s[1] = 'a';

while it's perfectly legal to do
char s[] = "Hello"; s[1] = 'a';

Thx in advans,
Karthik Balaguru

[Richard Bos]

karthikbalaguru <ka************ ***@gmail.comwr ote:

While trying to understand the difference between the following 2
methods, i have some interesting queries.
Method 1) char *s = "Hello";
and
Method 2) char s[] = "Hello";

How does the string 'hello' in first method lie in read-only memory

Who says it does? It _may_, because it's a string literal, and string
literals are allowed to be non-modifiable. To be exact, modifying the
contents of the array that is created to hold the string literal has
undefined behaviour, which means that anything may happen, from the
modification succeeding, through it being ignored, crashing the program,
and if the implementation is being intentionally malevolent, anything up
to sending lurid emails in your name to CERT-In.

and the string 'hello' in second method lie in a modifiable memory ?

Because it's a normal object, which is initialised from a string
literal; but once initialised, it is a normal, modifiable array object.

Only 'const' provides the 'Read-only' functionality in C .

Wrong.

How come this "char *s" provides that functionality ?

It doesn't; the fact that it points at a string literal does. Had you
pointed the pointer at a char array _object_ rather than at a string
literal, you could have modified it.

What is the internal of this functionality actually ?

That sentence no meaning.

Richard

[Chris Dollin]

karthikbalaguru wrote:

While trying to understand the difference between the following 2
methods, i have some interesting queries.
Method 1) char *s = "Hello";
and
Method 2) char s[] = "Hello";

How does the string 'hello' in first method lie in read-only memory

It /may/ lie in read-only memory. It's not /required/ to.

and the string 'hello' in second method lie in a modifiable memory ?

The standard says it's undefined behaviour to write into a string
literal. So an implementation can put string literals in read-only
memory because, if anyone writes into them, the standard says All
Bets Are Off.

Only 'const' provides the 'Read-only' functionality in C .

Not really true.

How come this "char *s" provides that functionality ?

It doesn't. It's not to do with `char *` ness. It's to do with
"Hello" being a string literal. You're not allowed to modify
the contents thereof.

In the second initialisation `char s[] = "Hello";`, the /content/
of that literal is copied into the store allocated for `s`. (And
that content doesn't change, since if you tried, you'd get UB.)
Since you don't get access to the insides of the literal, whether
or not it happened to be read-only doesn't matter. Indeed, the
implementation might not need to keep the literal around at all.

[It might, as an implementation-specific example, implement

char s[] = "f";

inside a function as

mov r0, #'f'
str r0, [fp], #offsetOf(s)

so that the content of the literal string ends up encoded in
the immediate value of the `ldr` instruction.]

--
Chris "the long arm of the lore" Dollin

Hewlett-Packard Limited registered office: Cain Road, Bracknell,
registered no: 690597 England Berks RG12 1HN

[pete]

karthikbalaguru wrote:

>
Hi,

While trying to understand the difference between the following 2
methods, i have some interesting queries.
Method 1) char *s = "Hello";
and
Method 2) char s[] = "Hello";

How does the string 'hello' in first method lie in read-only memory

What should the following code do?

char *s = "Hello";

*s = '\0';
puts("Hello");

Even if the meaning of that code wasn't explicitly
made undefined by the C standard,
it is obviously ambiguous code.

--
pete

[karthikbalaguru]

>

Only 'const' provides the 'Read-only' functionality in C .

Not really true.

Sorry, i should have used that in a clear fashion.
For true compile-time constant , we need to use '#define' or perhaps
'enum'.
For run time constants, we need to use 'const' telling that it can not
be manipulated/changed.
I think, the above is true now.
Is there something else that makes it false ?

[Chris Dollin]

karthikbalaguru wrote:

Only 'const' provides the 'Read-only' functionality in C .

Not really true.

Sorry, i should have used that in a clear fashion.
For true compile-time constant , we need to use '#define' or perhaps
'enum'.
For run time constants, we need to use 'const' telling that it can not
be manipulated/changed.
I think, the above is true now.
Is there something else that makes it false ?

String literals are effectively read-only. Hence, it is not true that

Only 'const' provides the 'Read-only' functionality in C .

--
Chris "can listen as well as read, eg, Hatfield And The North." Dollin

Hewlett-Packard Limited registered office: Cain Road, Bracknell,
registered no: 690597 England Berks RG12 1HN

[Richard]

pete <pf*****@mindsp ring.comwrites:

karthikbalaguru wrote:

>>
Hi,

While trying to understand the difference between the following 2
methods, i have some interesting queries.
Method 1) char *s = "Hello";
and
Method 2) char s[] = "Hello";

How does the string 'hello' in first method lie in read-only memory

What should the following code do?

char *s = "Hello";

*s = '\0';
puts("Hello");

Even if the meaning of that code wasn't explicitly
made undefined by the C standard,
it is obviously ambiguous code.

I don't think it is obvious at all.

[Jens Thoms Toerring]

Richard <rg****@gmail.c omwrote:

pete <pf*****@mindsp ring.comwrites:

karthikbalaguru wrote:

While trying to understand the difference between the following 2
methods, i have some interesting queries.
Method 1) char *s = "Hello";
and
Method 2) char s[] = "Hello";

How does the string 'hello' in first method lie in read-only memory

What should the following code do?

char *s = "Hello";

*s = '\0';
puts("Hello");

Even if the meaning of that code wasn't explicitly
made undefined by the C standard,
it is obviously ambiguous code.

I don't think it is obvious at all.

I guess Pete meant (but didn't explicitly wrote so) that the compiler
is free to use the same memory location for string literals whereever
they appear. In this case the "Hello" from the initialization of the
pointer could be at the same address as the "Hello" used as the argu-
ment to puts(). So if one managed to change the memory where "Hello"
resides then what puts() prints out is dependent on if the compiler
did this space-optimization or not.

Regards, Jens
--
\ Jens Thoms Toerring ___ [e-mail]
\______________ ____________ http://toerring.de

[Richard]

[e-mail] (Jens Thoms Toerring) writes:

Richard <rg****@gmail.c omwrote:

>pete <pf*****@mindsp ring.comwrites:

karthikbalaguru wrote:
While trying to understand the difference between the following 2
methods, i have some interesting queries.
Method 1) char *s = "Hello";
and
Method 2) char s[] = "Hello";

How does the string 'hello' in first method lie in read-only memory

What should the following code do?

char *s = "Hello";

*s = '\0';
puts("Hello");

Even if the meaning of that code wasn't explicitly
made undefined by the C standard,
it is obviously ambiguous code.

>I don't think it is obvious at all.

I guess Pete meant (but didn't explicitly wrote so) that the compiler
is free to use the same memory location for string literals whereever
they appear. In this case the "Hello" from the initialization of the
pointer could be at the same address as the "Hello" used as the argu-
ment to puts(). So if one managed to change the memory where "Hello"
resides then what puts() prints out is dependent on if the compiler
did this space-optimization or not.

No, I know how it works (or could work). I am just saying that it is not
obvious for a new C programmer.

>
Regards, Jens

--

[Keith Thompson]

karthikbalaguru <ka************ ***@gmail.comwr ites:

Only 'const' provides the 'Read-only' functionality in C .

Not really true.

Sorry, i should have used that in a clear fashion.
For true compile-time constant , we need to use '#define' or perhaps
'enum'.
For run time constants, we need to use 'const' telling that it can not
be manipulated/changed.
I think, the above is true now.
Is there something else that makes it false ?

Remember that "const" doesn't really mean "constant"; it merely means
"read-only". For example, 42 is a constant, but:
const int x = 42;
x is not a constant; it's merely read-only. (But the compiler can
choose to store x in read-only memory, or not store it at all if its
address is never used; nevertheless, x can't be used where a constant
expression is required.)

Attempting to *directly* modify something declared as "const" is
illegal (a constraint violation, requiring a diagnostic):
x = 43; /* ILLEGAL */

If you attempt to *indirectly* modify something declared as "const",
the compiler isn't required to complain, but the behavior is
undefined:
int *ptr = (int*)&x; /* the cast discards the "const"; bad idea */
*ptr = 43; /* UNDEFINED BEHAVIOR */

A string literal is not "const" (for historical reasons) but any
attempt to modify the contents of a string literal also invokes
undefined behavior. This isn't because it's const (it isn't); it's
because the standard explicitly says that it's undefined behavior.
The language would be a bit cleaner if string literals actually were
"const", but that would have broken old code written before "const"
was introduced to the language.

If you write:
char *s = "hello"; /* DANGEROUS */
you're treading on dangerous ground. The initialization is legal,
because the string literal isn't const, but it means that the compiler
isn't required to complain if you try to modify *s or s[0]. Doing so
might happen to work, or it might blow up in your face. To be safe,
*pretend* that string literals are really const:
const char *s = "hello"; /* BETTER */

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"