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

On Tue, 16 Oct 2007 20:40:18 +0000, Default User wrote:
> $)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.

If you consider the standard library part of the program, then yes, it's
true of every variable. (Or as Keith Thompson pointed out, every non-
volatile variable.) I did not consider it as a part when I wrote the
above.

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

I haven't claimed otherwise. Please don't pretend I did. What does
"disallowed" mean to you? The standard allows

int main(void a) {
a = 1;
return ++-a;
}

to be accepted by a conforming implementation, and to be considered a
conforming program, despite its constraint violations. The standard allows

int main(void) {
int a = -1;
return ++a * ++a;
}

to be rejected despite /not/ containing any constraint violations. A
diagnostic is required for the first example, and not the second, but
this diagnostic could be "remark: main is not capitalised", the
implementation could continue to produce a functional executable, and the
implementation would still be conforming.

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

Through a pointer to the literal, just like with strings.

int main(void) {
*(char *) 0x4004C8 = 0;
return 1;
}

You have to find some other way to get that pointer, but if you believe
that significantly changes things, please explain why.

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

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?

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

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.

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

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.

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

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.

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