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.

$)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

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.

$)CHarald van D)&k wrote:

> 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,

Ummm, that's true of every variable.

> and that all such actions by the
> program are not allowed by the language.

The actions constitute undefined behavior. If they were disallowed,
then they'd require a diagnostic.

> 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.

You're missing the point. The strings are not required to be constant.

The effect is that programs that don't treat the strings as if they
were constant exhibit UB, but that's NOT the same thing. Details
matter. Meanings matter.



Brian

On Tue, 16 Oct 2007 19:37:46 +0000, Default User wrote:
> $)CHarald van D)&k wrote:
>> 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,
>
> Ummm, that's true of every variable.

Consider errno, for an easy example.

>> and that all such actions by the
>> program are not allowed by the language.
>
> The actions constitute undefined behavior. If they were disallowed, then
> they'd require a diagnostic.

Constraint violations require a diagnostic, but a constraint violation is
disallowed about as much as undefined behaviour. In both cases, the
compiler is allowed to choose whether to accept or to reject the program,
and in both cases, if it accepts, what happens when the program is run is
beyond standard C. They differ in that constraint violations require some
sort of diagnostic, and that it's possible for constraint violations can
occur in code that would not otherwise be executed, but I believe that's
all.

>> 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.
>
> You're missing the point. The strings are not required to be constant.
>
> The effect is that programs that don't treat the strings as if they were
> constant exhibit UB, but that's NOT the same thing. Details matter.
> Meanings matter.

Well, then there are simply no constants in C. Even the values of integer
literals can be changed during program execution. How constant does
something have to be for you to consider it a constant?

"Default User" <defaultuserbr@yahoo.com> writes:
> $)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) kst-u@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"

$)CHarald van D)&k wrote:

> On Tue, 16 Oct 2007 19:37:46 +0000, Default User wrote:
> > $)CHarald van D)&k wrote:
> >> 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,
> >
> > Ummm, that's true of every variable.
>
> Consider errno, for an easy example.

What about it? The standard library functions are part of the program.

> >> and that all such actions by the
> >> program are not allowed by the language.
> >
> > The actions constitute undefined behavior. If they were disallowed,
> > then they'd require a diagnostic.
>
> Constraint violations require a diagnostic, but a constraint
> violation is disallowed about as much as undefined behaviour. In both
> cases, the compiler is allowed to choose whether to accept or to
> reject the program, and in both cases, if it accepts, what happens
> when the program is run is beyond standard C. They differ in that
> constraint violations require some sort of diagnostic, and that it's
> possible for constraint violations can occur in code that would not
> otherwise be executed, but I believe that's all.

You have a different definition of "disallowed" than I do. I believe
the standard when it says it imposes no requirements.

> > You're missing the point. The strings are not required to be
> > constant.
> >
> > The effect is that programs that don't treat the strings as if they
> > were constant exhibit UB, but that's NOT the same thing. Details
> > matter. Meanings matter.
>
> Well, then there are simply no constants in C. Even the values of
> integer literals can be changed during program execution.

Not through normal assignment.


You're entitled to your opinion on the subject, but I don't find it to
be compelling.





Brian

Keith Thompson wrote:

> "Default User" <defaultuserbr@yahoo.com> writes:
> > $)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