Question1
I understand that const is 'read-only' but I could not convince my
co-worker that its value can change.

6.7.8 Initialization

[...]

[#4] All the expressions in an initializer for an object
that has static storage duration shall be constant
expressions or string literals.

Can someone point me to text that says that 'const' is not 'constant
expression' and can in fact change?

He claims that the compiler may choose to substitute the value at
compile time.
I tried to explain how the value can change (but I had to use pointers
to const int) which he shot down saying the comparison of examples is
not valid (it's not initializer and it involves pointers).

Question2
Moreover, if we turn on optimization, (and assume that the real code
does not have any dead code like above), the compiler does not give any
error. Is the compiler correct after optimisation?
I think it is a bug in compiler but I need text in standard to prove
that.

Whether or not it can is of no import to that error. It is not a
constant, as defined by the Standard. That's all that matters.
<http://c-faq.com/ansi/constasconst.html>.
> 6.7.8 Initialization
>
> [...]
>
> [#4] All the expressions in an initializer for an object
> that has static storage duration shall be constant
> expressions or string literals.
>
> Can someone point me to text that says that 'const' is not 'constant
> expression' and can in fact change?

Any object, whether const or not, is not a constant expression: 6.6.
"Can in fact change": immaterial.
> He claims that the compiler may choose to substitute the value at
> compile time.

He may claim whatever he wants. It remains a const object, not a
constant expression, and is therefore not a portable initaliser.
> Moreover, if we turn on optimization, (and assume that the real code
> does not have any dead code like above), the compiler does not give any
> error. Is the compiler correct after optimisation?

By 6.6#10, yes. However, no other compiler (nor even the same compiler
the next time) is required to accept its extensions.

It fails here, at runtime, but only because "a" has been placed into
read-only memory on this platform. But it's perfectly "legal" C, as
far as I know. It compiles without even a warning about "pt" and "a",
even with maximum warnings turned on.

Please provide context when replying. Usenet is not Google Groups,
Google Groups is merely on of many Usenet service provides that provides
a poor interface. There is no guarantee that others have (or ever will)
see the post you are replying to.
> If the compiler can treat this 'a' as a compile time constant then this
> should also work
>
> const int size = 5;
> int array[size];
>
> But seems like it does not compile even with optimizations.
>
> This is causing confusion.

Basically, you can't do it because the standard says you can't. const in
C is a promise that you will not attempt to modify something, it does
not declare a real constant. So, for example, you can do:
volatile const int fred;
Then, you might be able to use some magic in your linker to map fred
over a hardware register and each time you read it you will get the
current contents of that register.

It's legal C syntax and no diagnostic is required, but the attempt to
modify a const qualified object invokes undefined behaviour. The reason
for this is, I believe, specifically so that implementations *can* put
const qualified objects in to read only memory, so you implementation is
quite within its rights to do this. To quote from section 6.7.3 of
n1124.pdf:
| Semantics
| ...
| 5 If an attempt is made to modify an object defined with a
| const-qualified type through use of an lvalue with
| non-const-qualified type, the behavior is undefined...
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:http://clc-wiki.net/wiki/Intro_to_clc

Kenneth Brody wrote:
> Isn't this legal?
>
> ==========
>
> #include <stdio.h>
>
> const int a = 10;
> int *pt = (int *)&a;
> It fails here, at runtime, but only because "a" has been placed into
> read-only memory on this platform. But it's perfectly "legal" C, as
> far as I know. It compiles without even a warning about "pt" and "a",
> even with maximum warnings turned on.

What do you mean by "legal"? It doesn't require a diagnostic, but it's
undefined behavior.

Guest

Marc Boyer wrote:
> Le 19-04-2006, <> a écrit :
> > Thanks Marc, point noted.
> >
> > Now getting back to my example,
> >
> > const int a = 10;
> >
> > In this case, can value of 'a' change?
>
> Not to my knowledge.
>
> > If so how?
> > If not, why can not variable 'a' be treated a compile time constant.
>
> It 'can' in this case. But, just try to explain in wich case
> it can and when it can not....

My bad. I did not include complete text.
Let me include enough context and repost.

No strictly conforming program can change its value. Whether or not
it can change makes no difference.
> 6.7.8 Initialization
>
> [...]
>
> [#4] All the expressions in an initializer for an object
> that has static storage duration shall be constant
> expressions or string literals.
>
> Can someone point me to text that says that 'const' is not 'constant
> expression' and can in fact change?

Nothing in the standard states that a const object may change. But
there is a precise definition of what constitutes a constant
expression, in 6.6 Constant expressions. Nowhere in that section does
it include the value of an object, regardless of const qualification,
as a constant expression.
> He claims that the compiler may choose to substitute the value at
> compile time.
> I tried to explain how the value can change (but I had to use pointers
> to const int) which he shot down saying the comparison of examples is
> not valid (it's not initializer and it involves pointers).

It is no longer a C program if you attempt to change an object defined
with the const qualifier.
> Question2
> Moreover, if we turn on optimization, (and assume that the real code
> does not have any dead code like above), the compiler does not give any
> error. Is the compiler correct after optimisation?

The compiler is neither correct nor incorrect, see below.
> I think it is a bug in compiler but I need text in standard to prove
> that.

No, it's not a bug in the compiler. But it is not portable behavior
either. Paragraph 10 of 6.6 consists of one sentence, which is "An
implementation may accept other forms of constant expressions."

So if your implementation happens to define the value of an object
defined with the const qualifier and an initializer, in scope, as a
constant expression, apparently the standard allows it to.

Le 19-04-2006, <> a écrit :
> Marc Boyer wrote:
>> Le 19-04-2006, <> a écrit :
>> > Thanks Marc, point noted.
>> >
>> > Now getting back to my example,
>> >
>> > const int a = 10;
>> >
>> > In this case, can value of 'a' change?
>>
>> Not to my knowledge.
>>
>> > If so how?
>> > If not, why can not variable 'a' be treated a compile time constant.
>>
>> It 'can' in this case. But, just try to explain in wich case
>> it can and when it can not....
>
>
> My bad. I did not include complete text.
> Let me include enough context and repost.
>
> ~> cat test.c
> const int a = 10;
> int main () {
> static int b = a;
> return b;
> }
>
> If the compiler can treat this 'a' as a compile time constant then this
> should also compile.

It depend what you mean by 'the compiler can'. I think that, if
someone is able to write a C compiler, he would also be able to
write a augmented C compiler that, *in this special case*,
see that a is constant at compile time.

You should notice also that this is a valid C++ code,
but C++ does not require that static variable are initialized
by constant.

But in C, there is a standard that defines what must be accepted
by a C compiler. In this case, it may be detected because the value
of your const variable can be known at compile time By, in this case,
it should also accept
int main(){
int a=1;
static int b=a;
a--;
return a;
}

In this case, a is not any more a constant, but b is always
initialized with value 1.

And what about
const int a= random()?1:1;
or
const int a= random()?1:10/10;

What I mean is that, in the general case, it is hard (perhaps
undecidable in fact) to know when a const variable is a compile time
constant, and whan is is not. But, what is sure is that a constant
expression is a compile time constant. Then, the people who wrote
the standard have chosen to allow only initialisation of static
variable with constant expression.

Share This Page

Welcome to The Coding Forums!

Welcome to the Coding Forums, the place to chat about anything related to programming and coding languages.

Please join our friendly community by clicking the button below - it only takes a few seconds and is totally free. You'll be able to ask questions about coding or chat with the community and help others.
Sign up now!