constant string doubt

[sinbad]

hi,
why does the following program gives an runtime error ,instead of
compilation error. anyone please shed
some light.

thanks
sinbad

------------------------------
int main()
{
char *a = "abcdefgh";
a[1] = 'j';
printf("%s",a);
}
----------------------------------

[Peter Nilsson]

sinbad <[e-mail]:

hi,
why does the following program gives an runtime error ,
instead of compilation error. anyone please shed
some light.

thanks
sinbad

------------------------------
int main()
{
char *a = "abcdefgh";
a[1] = 'j';
printf("%s",a);}

----------------------------------

Because you failed to read the FAQ...

http://c-faq.com/decl/strlitinit.html

--
Peter

[Jack Klein]

On Mon, 15 Oct 2007 18:33:52 -0700, sinbad <si***********@gmail.com>
wrote in comp.lang.c:

hi,
why does the following program gives an runtime error ,instead of
compilation error. anyone please shed
some light.

thanks
sinbad

------------------------------
int main()
{
char *a = "abcdefgh";
a[1] = 'j';
printf("%s",a);
}
----------------------------------

Your program produces two different types of undefined behavior.

First you call the variadic function printf() without a prototype in
scope, undefined behavior.

Second you attempt to modify an element of a string literal, which is
specifically undefined behavior as stated by the C standard.

A compiler is never required to issue a diagnostic for undefined
behavior.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

[naala]

On Oct 15, 6:33 pm, sinbad <[e-mail]:

hi,
why does the following program gives an runtime error ,instead of
compilation error. anyone please shed
some light.

thanks
sinbad

------------------------------
int main()
{
char *a = "abcdefgh";
a[1] = 'j';
printf("%s",a);}

----------------------------------

'a' is an instance of non-constant pointer to the constant
data"abcdefgh".
so,you are not allowed to change the data using pointers.

[Mark Bluemel]

naala wrote:

On Oct 15, 6:33 pm, sinbad <[e-mail]:

>hi,
why does the following program gives an runtime error ,instead of
compilation error. anyone please shed
some light.

thanks
sinbad

------------------------------
int main()
{
char *a = "abcdefgh";
a[1] = 'j';
printf("%s",a);}

----------------------------------

'a' is an instance of non-constant pointer to the constant
data"abcdefgh".
so,you are not allowed to change the data using pointers.

I don't think you've got that right. Let me give you a counter example -
that program will probably run just fine (for some value of the term
"fine") on some implementations, and on some others it will run fine
(for some value...) if run under the control of the debugger.

The basic issue is discussed in the FAQ at http://www.c-faq.com, I
suggest the original poster goes there for a correct explanation.

[Charlie Gordon]

"sinbad" <si***********@gmail.coma écrit dans le message de news:
11*********************@e9g2000prf.googlegroups.co m...

hi,
why does the following program gives an runtime error ,instead of
compilation error. anyone please shed
some light.

thanks
sinbad

------------------------------
int main()
{
char *a = "abcdefgh";
a[1] = 'j';
printf("%s",a);
}
----------------------------------

String literals were not made const to avoid breaking a lot of historical C
programs. Yet modifying them invokes undefined behaviour. It is better
practice to use const char * to point to them. gcc for instance has a
special mode where it tries to enforce this:

gcc -Wall -W -O2 -Wwrite-strings test.c

will get the appropriate warning, along with a few others:

test.c: In function `main':
test.c:3: warning: initialization discards qualifiers from pointer target
type
test.c:5: warning: implicit declaration of function `printf'
test.c:6: warning: control reaches end of non-void function

There is still another problem that gcc did not catch: writing to stdout
without a final \n has implementation defined behaviour.

--
Chqrlie.

[Jack Klein]

On Mon, 15 Oct 2007 22:03:30 -0700, naala <ne***********@gmail.com>
wrote in comp.lang.c:

On Oct 15, 6:33 pm, sinbad <[e-mail]:

hi,
why does the following program gives an runtime error ,instead of
compilation error. anyone please shed
some light.

thanks
sinbad

------------------------------
int main()
{
char *a = "abcdefgh";
a[1] = 'j';
printf("%s",a);}

----------------------------------

'a' is an instance of non-constant pointer to the constant
data"abcdefgh".

By definition in the C standard, the type of a string literal like
"abcdefgh" in the above program is array of char, and NOT array of
const char. "abcdefgh" is not constant data in C.

so,you are not allowed to change the data using pointers.

Attempting to modify a string literal in C causes undefined behavior.
This is not because the string literal is constant, but because the C
standard specifically states that this is so.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

[=?iso-2022-kr?q?=1B=24=29CHarald_van_D=0E=29=26=0F]

On Tue, 16 Oct 2007 12:03:43 -0500, Jack Klein wrote:

By definition in the C standard, the type of a string literal like
"abcdefgh" in the above program is array of char, and NOT array of const
char. "abcdefgh" is not constant data in C.

It is not const-qualified, but it is constant.

[Default User]

$)CHarald van D)&k wrote:

On Tue, 16 Oct 2007 12:03:43 -0500, Jack Klein wrote:

By definition in the C standard, the type of a string literal like
"abcdefgh" in the above program is array of char, and NOT array of
const char. "abcdefgh" is not constant data in C.

It is not const-qualified, but it is constant.

It may or may not be. It is undefined behavior to attempt to modify the
contents of a string literal.

Brian

[=?iso-2022-kr?q?=1B=24=29CHarald_van_D=0E=29=26=0F]

On Tue, 16 Oct 2007 19:14:07 +0000, Default User wrote:

$)CHarald van D)&k wrote:

>On Tue, 16 Oct 2007 12:03:43 -0500, Jack Klein wrote:

By definition in the C standard, the type of a string literal like
"abcdefgh" in the above program is array of char, and NOT array of
const char. "abcdefgh" is not constant data in C.

It is not const-qualified, but it is constant.

It may or may not be. It is undefined behavior to attempt to modify the
contents of a string literal.

It's constant in that its value isn't allowed to change without a
specific action by the program, and that all such actions by the program
are not allowed by the language. If you perform such an action anyway,
then sure, it's possible for its value to change, just like it's possible
for the value of a const-qualified object to change.

[Keith Thompson]

"Default User" <de***********@yahoo.comwrites:

$)CHarald van D)&k wrote:

[...]

>It's constant in that its value isn't allowed to change without a
specific action by the program,

Ummm, that's true of every variable.

<quibble>It's true of every non-volatile variable.</quibble>

[...]

--
Keith Thompson (The_Other_Keith) 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"

[Default User]

Keith Thompson wrote:

"Default User" <de***********@yahoo.comwrites:

$)CHarald van D)&k wrote:

[...]

It's constant in that its value isn't allowed to change without a
specific action by the program,

Ummm, that's true of every variable.

<quibble>It's true of every non-volatile variable.</quibble>

Right, I thought about that afterwards.

Brian

[Default User]

$)CHarald van D)&k wrote:

That would be why I'm trying to explain why I believe what I do, and
why I've asked you a question to clarify your position. You have not
answered my question, so I will ask it again: how constant does
something have to be for you to consider it constant?

All you've demonstrated so far is that nothing is a constant. That's
not exactly your going-in position.


Brian

[=?iso-2022-kr?q?=1B=24=29CHarald_van_D=0E=29=26=0F]

On Tue, 16 Oct 2007 21:07:11 +0000, Default User wrote:

$)CHarald van D)&k wrote:

>That would be why I'm trying to explain why I believe what I do, and
why I've asked you a question to clarify your position. You have not
answered my question, so I will ask it again: how constant does
something have to be for you to consider it constant?

All you've demonstrated so far is that nothing is a constant. That's not
exactly your going-in position.

Quoting myself from a few messages back:

Well, then there are simply no constants in C.

While by my definition of constant, they do exist in C, I also accept
that there are legitimate alternative definitions by which they do not.

But you still haven't answered my question. If you can explain to me
where you draw the line between constants and non-constants, then it
becomes possible to tell whether your interpretation (even while
different from mine) is self-consistent. If it is, then I disagree with
your terminology, but may agree with your conclusions. If it is not, then
I do not agree with either your terminology or your conclusions.

[Default User]

$)CHarald van D)&k wrote:

On Tue, 16 Oct 2007 21:07:11 +0000, Default User wrote:

$)CHarald van D)&k wrote:

That would be why I'm trying to explain why I believe what I do,

and >why I've asked you a question to clarify your position. You
have not >answered my question, so I will ask it again: how
constant does >something have to be for you to consider it constant?

All you've demonstrated so far is that nothing is a constant.
That's not exactly your going-in position.

Quoting myself from a few messages back:

Well, then there are simply no constants in C.

Not, however, your going-in position.

While by my definition of constant, they do exist in C, I also accept
that there are legitimate alternative definitions by which they do
not.

But you still haven't answered my question. If you can explain to me
where you draw the line between constants and non-constants, then it
becomes possible to tell whether your interpretation (even while
different from mine) is self-consistent. If it is, then I disagree
with your terminology, but may agree with your conclusions. If it is
not, then I do not agree with either your terminology or your
conclusions.

Well, one definition would be anything const-qualified plus anything
that is a(n): integer-constant, floating-constant,
enumeration-constant, or character-constant.

Of course, that's not quite what I said orginally, plus you already
know that string literals aren't const-qualified. So with that I would
have to be less waffly and just say that string literals are not
constant at all.


Brian

[=?iso-2022-kr?q?Harald_van_D=0E=29=26=0Fk?=]

On Tue, 16 Oct 2007 22:19:55 +0000, Default User wrote:

$)CHarald van D)&k wrote:

>On Tue, 16 Oct 2007 21:07:11 +0000, Default User wrote:

All you've demonstrated so far is that nothing is a constant. That's
not exactly your going-in position.

Quoting myself from a few messages back:

Well, then there are simply no constants in C.

Not, however, your going-in position.

True.

>While by my definition of constant, they do exist in C, I also accept
that there are legitimate alternative definitions by which they do not.

But you still haven't answered my question. If you can explain to me
where you draw the line between constants and non-constants, then it
becomes possible to tell whether your interpretation (even while
different from mine) is self-consistent. If it is, then I disagree with
your terminology, but may agree with your conclusions. If it is not,
then I do not agree with either your terminology or your conclusions.

Well, one definition would be anything const-qualified plus anything
that is a(n): integer-constant, floating-constant, enumeration-constant,
or character-constant.

Thanks. I don't think this definition would lead to contradictions either
way, but out of curiosity, which of the below would qualify as a constant?

const int a = 0;
const int *p = &a;
*p;

const int a = 0;
int *p = (int *) &a;
*p;

int a = 0;
const int *p = &a;
*p;

Of course, that's not quite what I said orginally, plus you already know
that string literals aren't const-qualified. So with that I would have
to be less waffly and just say that string literals are not constant at
all.

With that definition of constant, indeed, they are not. I preferred to
define a constant based on its behaviour and restrictions, but this works
as well.

[Default User]

Harald van D)&k wrote:

On Tue, 16 Oct 2007 22:19:55 +0000, Default User wrote:

Well, one definition would be anything const-qualified plus anything
that is a(n): integer-constant, floating-constant,
enumeration-constant, or character-constant.

Thanks. I don't think this definition would lead to contradictions
either way, but out of curiosity, which of the below would qualify as
a constant?

Now you're going to make me think some more, aren't you? It was hard
enough yesterday. I wasn't expecting a sort of Spanish In. . . no,
better not go there.

const int a = 0;
const int *p = &a;
*p;

Yes. I believe the deference of a const pointer results in a
const-qualified object, although I can't quote any scripture on that.

const int a = 0;
int *p = (int *) &a;
*p;

No. You've "casted away constness", so it's not a constant. Obviously
UB is lurking.

int a = 0;
const int *p = &a;
*p;

Yes. Same reason as 1.

Of course, that's not quite what I said orginally, plus you already
know that string literals aren't const-qualified. So with that I
would have to be less waffly and just say that string literals are
not constant at all.

With that definition of constant, indeed, they are not. I preferred
to define a constant based on its behaviour and restrictions, but
this works as well.

I'm guessing (correct me if wrong) that if attempts to modify an object
result in a constraint violation or UB, then it's a "constant"?


Brian

[=?iso-2022-kr?q?=1B=24=29CHarald_van_D=0E=29=26=0F]

On Wed, 17 Oct 2007 19:38:28 +0000, Default User wrote:

Harald van D)&k wrote:

>On Tue, 16 Oct 2007 22:19:55 +0000, Default User wrote:

Well, one definition would be anything const-qualified plus anything
that is a(n): integer-constant, floating-constant,
enumeration-constant, or character-constant.

Thanks. I don't think this definition would lead to contradictions
either way, but out of curiosity, which of the below would qualify as a
constant?

Now you're going to make me think some more, aren't you? It was hard
enough yesterday. I wasn't expecting a sort of Spanish In. . . no,
better not go there.

I have no more questions :)

>const int a = 0;
const int *p = &a;
*p;

Yes. I believe the deference of a const pointer results in a
const-qualified object, although I can't quote any scripture on that.

To be precise, the dereference of a pointer-to-const results in an lvalue
expression having some const-qualified type. Whether the object is const-
qualified is again open to interpretation, since there are two types that
are relevant: the effective type, and the type of the expression used to
access it.

>const int a = 0;
int *p = (int *) &a;
*p;

No. You've "casted away constness", so it's not a constant. Obviously UB
is lurking.

Indeed, you're only allowed to read *p, not modify it, even though *p
isn't const-qualified.

>int a = 0;
const int *p = &a;
*p;

Yes. Same reason as 1.

Of course, that's not quite what I said orginally, plus you already
know that string literals aren't const-qualified. So with that I
would have to be less waffly and just say that string literals are
not constant at all.

With that definition of constant, indeed, they are not. I preferred to
define a constant based on its behaviour and restrictions, but this
works as well.

I'm guessing (correct me if wrong) that if attempts to modify an object
result in a constraint violation or UB, then it's a "constant"?

That's very close. If an object's value or effective type can change
without UB, then I do not consider it a constant, and otherwise I do. So
for the above examples, I would consider 1 and 2 constant, rather than 1
and 3. I don't consider example 3 constant, because you're allowed to
modify *p either by casting away the const qualifier, or by modifying a
directly.

[Default User]

$)CHarald van D)&k wrote:

On Wed, 17 Oct 2007 19:38:28 +0000, Default User wrote:

I'm guessing (correct me if wrong) that if attempts to modify an
object result in a constraint violation or UB, then it's a
"constant"?

That's very close. If an object's value or effective type can change
without UB, then I do not consider it a constant, and otherwise I do.
So for the above examples, I would consider 1 and 2 constant, rather
than 1 and 3. I don't consider example 3 constant, because you're
allowed to modify *p either by casting away the const qualifier, or
by modifying a directly.

You didn't cast it away, so that as written it (I think) requires a
diagnostic to modify it through *p. As you say, you can go back to a
itself and back-door modify *p. That's a good point.

Brian