Explanation needed for const int "error: variably modified ... at file scope."
Poster Matt
The following code results in the following error with GCC (v.4.3.2):
const int eodSize = 8192;
char eodContents[eodSize];
error: variably modified 'eodContents' at file scope
It is, of course, easily solved by ditching the 'const int' and using a #define
instead like this:
#define eodSize 8192
char eodContents[eodSize];
I would understand the error if "const int eodSize = 8192;" was not a constant
but since it is a constant why does the compiler not allow it?
Thanks.
bart.c
"Poster Matt" <postermatt@no_spam_for_me.org> wrote in message
news:bbQRn.22678$YG4....@newsfe10.ams2...
const doesn't mean what you think.
Just use:
enum {eodSize=8192};
as #define has it's own problems.
--
Bartc
Ben Pfaff
> The following code results in the following error with GCC (v.4.3.2):
>
> const int eodSize = 8192;
> char eodContents[eodSize];
This is in the FAQ:
11.8: I don't understand why I can't use const values in initializers
and array dimensions, as in
const int n = 5;
int a[n];
A: The const qualifier really means "read-only"; an object so
qualified is a run-time object which cannot (normally) be
assigned to. The value of a const-qualified object is therefore
*not* a constant expression in the full sense of the term. (C
is unlike C++ in this regard.) When you need a true compile-
time constant, use a preprocessor #define (or perhaps an enum).
References: ISO Sec. 6.4; H&S Secs. 7.11.2,7.11.3 pp. 226-7.
--
"When in doubt, treat ``feature'' as a pejorative.
(Think of a hundred-bladed Swiss army knife.)"
--Kernighan and Plauger, _Software Tools_
Keith Thompson
Because "const" doesn't mean "constant"; it really means "read-only".
The language *could* have stated that a const object with an
initializer that's a constant expression is a constant <OT>as C++
does</OT>, but it doesn't.
Note that this is legal (at block scope):
const int r = rand();
r obviously isn't constant (in the sense of being evaluable at compile
time), but it is "const", i.e., read-only, in the sense that you're
not allowed to modify it:
r = 42; /* constraint violation */
... at least not directly:
*(int*)&r = 42; /* undefined behavior, not a constraint violation */
bart.c points out the enum trick, which I find preferable to using
a macro:
enum { eodSize = 8192 };
One drawback is that enumeration constants can only be of type int.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Poster Matt
const means exactly what I think. It specifies that the value of the variable
will not be changed.
What on earth is wrong with using #define as I have used it above? It seems to
me to be perfectly fine. Note: "#define eodSize 8192" is not being defined
inside a function.
But I was looking for an explanation...
Cheers.
Poster Matt
> Poster Matt <postermatt@no_spam_for_me.org> writes:
>
>> The following code results in the following error with GCC (v.4.3.2):
>>
>> const int eodSize = 8192;
>> char eodContents[eodSize];
>
> This is in the FAQ:
>
> 11.8: I don't understand why I can't use const values in initializers
> and array dimensions, as in
>
> const int n = 5;
> int a[n];
>
> A: The const qualifier really means "read-only"; an object so
> qualified is a run-time object which cannot (normally) be
> assigned to. The value of a const-qualified object is therefore
> *not* a constant expression in the full sense of the term. (C
> is unlike C++ in this regard.) When you need a true compile-
> time constant, use a preprocessor #define (or perhaps an enum).
>
> References: ISO Sec. 6.4; H&S Secs. 7.11.2,7.11.3 pp. 226-7.
Oops, sorry. Thanks for the info.
Poster Matt
> bart.c wrote:
>>
>> "Poster Matt" <postermatt@no_spam_for_me.org> wrote in message
>> news:bbQRn.22678$YG4....@newsfe10.ams2...
>>> Hi,
>>>
>>> The following code results in the following error with GCC (v.4.3.2):
>>>
>>> const int eodSize = 8192;
>>> char eodContents[eodSize];
>>>
>>> error: variably modified 'eodContents' at file scope
>>>
>>>
>>> It is, of course, easily solved by ditching the 'const int' and using
>>> a #define instead like this:
>>>
>>> #define eodSize 8192
>>> char eodContents[eodSize];
>>>
>>> I would understand the error if "const int eodSize = 8192;" was not a
>>> constant but since it is a constant why does the compiler not allow it?
>>
>> const doesn't mean what you think.
>>
>> Just use:
>>
>> enum {eodSize=8192};
>>
>> as #define has it's own problems.
>
> const means exactly what I think. It specifies that the value of the
> variable will not be changed.
Ok I was a bit quick with my reply - it doesn't mean exactly what I thought it
meant. <Head held in shame smiley>
K&R is a bit unclear about it to say the least - see my reply to Keith.
Cheers.
Poster Matt
> Poster Matt <postermatt@no_spam_for_me.org> writes:
>> The following code results in the following error with GCC (v.4.3.2):
>>
>> const int eodSize = 8192;
>> char eodContents[eodSize];
>>
>> error: variably modified 'eodContents' at file scope
>>
>>
>> It is, of course, easily solved by ditching the 'const int' and using
>> a #define instead like this:
>>
>> #define eodSize 8192
>> char eodContents[eodSize];
>>
>> I would understand the error if "const int eodSize = 8192;" was not a
>> constant but since it is a constant why does the compiler not allow
>> it?
>
> Because "const" doesn't mean "constant"; it really means "read-only".
>
> The language *could* have stated that a const object with an
> initializer that's a constant expression is a constant <OT>as C++
> does</OT>, but it doesn't.
K&R is somewhat misleading then when it says:
"The qualifier const can be applied to any variable to specify that its value
will not be changed."
> Note that this is legal (at block scope):
>
> const int r = rand();
>
> r obviously isn't constant (in the sense of being evaluable at compile
> time), but it is "const", i.e., read-only, in the sense that you're
> not allowed to modify it:
>
> r = 42; /* constraint violation */
Ok got it.
> ... at least not directly:
>
> *(int*)&r = 42; /* undefined behavior, not a constraint violation */
>
> bart.c points out the enum trick, which I find preferable to using
> a macro:
>
> enum { eodSize = 8192 };
>
> One drawback is that enumeration constants can only be of type int.
Why is it in any way preferable to use this 'enum trick' to a #define?
Thanks Keith.
bart.c
> bart.c wrote:
>> "Poster Matt" <postermatt@no_spam_for_me.org> wrote in message
>> news:bbQRn.22678$YG4....@newsfe10.ams2...
>>> const int eodSize = 8192;
>>> char eodContents[eodSize];
>>>
>>> error: variably modified 'eodContents' at file scope
>>> It is, of course, easily solved by ditching the 'const int' and using a
>>> #define instead like this:
>>>
>>> #define eodSize 8192
>>> char eodContents[eodSize];
>>>
>>> I would understand the error if "const int eodSize = 8192;" was not a
>>> constant but since it is a constant why does the compiler not allow it?
>>
>> const doesn't mean what you think.
>>
>> Just use:
>>
>> enum {eodSize=8192};
>>
>> as #define has it's own problems.
>
> const means exactly what I think. It specifies that the value of the
> variable will not be changed.
Most people who ask that assume that 'const' defines an actual constant (not
a memory location containing a value). Your wording ("...but since it is a
constant ...") suggested you thought the same.
> What on earth is wrong with using #define as I have used it above? It
> seems to me to be perfectly fine. Note: "#define eodSize 8192" is not
> being defined inside a function.
Yes, #define names have too wide a visibility for many cases; enum doesn't
have that problem and comes closest to what some people expect 'const' to
do, at least for int values. But you seem to know all the answers already..
> But I was looking for an explanation...
I expected someone else to provide that; I just gave an alternative
workaround..
--
Bartc
>
> Cheers.
Seebs
> I would understand the error if "const int eodSize = 8192;" was not a constant
> but since it is a constant why does the compiler not allow it?
It is not a constant.
An object you can't write to is not a constant. You still have to look up
the value at runtime (since nothing prevents some other aspect of the system
from modifying the "constant" value).
-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
Richard Heathfield
> Keith Thompson wrote:
<snip>
>>
>> bart.c points out the enum trick, which I find preferable to using
>> a macro:
>>
>> enum { eodSize = 8192 };
>>
>> One drawback is that enumeration constants can only be of type int.
>
> Why is it in any way preferable to use this 'enum trick' to a #define?
Good question. Whilst #define is perhaps not perfect, its "problems" are
frequently exaggerated.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within
Keith Thompson
> Keith Thompson wrote:
>> Poster Matt <postermatt@no_spam_for_me.org> writes:
>>> I would understand the error if "const int eodSize = 8192;" was not a
>>> constant but since it is a constant why does the compiler not allow
>>> it?
>>
>> Because "const" doesn't mean "constant"; it really means "read-only".
>>
>> The language *could* have stated that a const object with an
>> initializer that's a constant expression is a constant <OT>as C++
>> does</OT>, but it doesn't.
>
> K&R is somewhat misleading then when it says:
>
> "The qualifier const can be applied to any variable to specify that
> its value will not be changed."
How is that unclear? As far as I can tell, it's perfectly accurate;
const specifies that the value of the variable (I would have said
"object") will not be changed. It doesn't specify that it's a
"constant" (where "constant" means roughly that its value can be
evaluated at compile time).
For example:
>> Note that this is legal (at block scope):
>>
>> const int r = rand();
>>
>> r obviously isn't constant (in the sense of being evaluable at compile
>> time), but it is "const", i.e., read-only, in the sense that you're
>> not allowed to modify it:
[...]
How could the statement in K&R be made clearer?
>> bart.c points out the enum trick, which I find preferable to using
>> a macro:
>>
>> enum { eodSize = 8192 };
>>
>> One drawback is that enumeration constants can only be of type int.
>
> Why is it in any way preferable to use this 'enum trick' to a #define?
>
> Thanks Keith.
The preprocessor is basically a language grafted on top of
another language, with radically different syntax and semantics.
A macro definition is not scoped; it remains visible from the
point of declaration to the end of the translation unit. In more
complex cases, you have to add extra parentheses and/or use the
"do ... while(0)" trick to avoid subtle conflicts between the macro
expansion and the language syntax.
For a simple case like
#define eodSize 8192
it's not too bad; you're probably not going to have anything
else with that name, so the scoping issue doesn't really matter.
(But note that the convention is for macro names to be all-caps:
EOD_SIZE -- but identifiers starting with E and either a digit
or another uppercase letter are reserved as error macro names
in <errno.h>.)
Macros, like any other language feature, are fine if you know what
you're doing, but they're particularly easy to misuse if you're
not careful. I personally prefer to use other language features
when possible.
Poster Matt
> Poster Matt <postermatt@no_spam_for_me.org> writes:
>> Keith Thompson wrote:
>>> Poster Matt <postermatt@no_spam_for_me.org> writes:
>
>> K&R is somewhat misleading then when it says:
>>
>> "The qualifier const can be applied to any variable to specify that
>> its value will not be changed."
>
> How is that unclear? As far as I can tell, it's perfectly accurate;
> const specifies that the value of the variable (I would have said
> "object") will not be changed. It doesn't specify that it's a
> "constant" (where "constant" means roughly that its value can be
> evaluated at compile time).
I'm not sure I should have said 'misleading', but it certainly does not tell the
whole story. To my mind the quotation above implies that the value specified in
the source code will not be changed. So I'd never have thought "const int r =
rand();" was allowed.
>> Why is it in any way preferable to use this 'enum trick' to a #define?
>>
>
> The preprocessor is basically a language grafted on top of
> another language, with radically different syntax and semantics.
> A macro definition is not scoped; it remains visible from the
> point of declaration to the end of the translation unit. In more
> complex cases, you have to add extra parentheses and/or use the
> "do ... while(0)" trick to avoid subtle conflicts between the macro
> expansion and the language syntax.
>
> For a simple case like
>
> #define eodSize 8192
>
> it's not too bad; you're probably not going to have anything
> else with that name, so the scoping issue doesn't really matter.
> (But note that the convention is for macro names to be all-caps:
> EOD_SIZE -- but identifiers starting with E and either a digit
> or another uppercase letter are reserved as error macro names
> in <errno.h>.)
>
> Macros, like any other language feature, are fine if you know what
> you're doing, but they're particularly easy to misuse if you're
> not careful. I personally prefer to use other language features
> when possible.
Ok, many thanks for the detailed explanation, it's appreciated. I still have a
lot to learn, funny that cos I thought I was getting pretty good. :)
Re: Macro variable name - the name in my actual code was quite long and
descriptive, so I made up a fake name for posting here. eodSize and eodContents
were named simply because I had a DVD rental on my desk of a Mel Gibson movie
called Edge of Darkness, when the thought entered my mind to make a more concise
name for posting, the DVD was in my field of view, hence 'eod'. I didn't
capitalize the #define version out of laziness when copying'n'pasting.
Thanks again. I've learnt another new thing about C today. I'll get there
eventually...(I hope).
Cheers.
Ben Bacarisse
> Keith Thompson wrote:
>> Poster Matt <postermatt@no_spam_for_me.org> writes:
>>> Keith Thompson wrote:
>>>> Poster Matt <postermatt@no_spam_for_me.org> writes:
>>
>>> K&R is somewhat misleading then when it says:
>>>
>>> "The qualifier const can be applied to any variable to specify that
>>> its value will not be changed."
>>
>> How is that unclear? As far as I can tell, it's perfectly accurate;
>> const specifies that the value of the variable (I would have said
>> "object") will not be changed. It doesn't specify that it's a
>> "constant" (where "constant" means roughly that its value can be
>> evaluated at compile time).
>
> I'm not sure I should have said 'misleading', but it certainly does
> not tell the whole story. To my mind the quotation above implies that
> the value specified in the source code will not be changed.
More than implies -- it says so explicitly and unambiguously!
> So I'd
> never have thought "const int r = rand();" was allowed.
There's really no contradiction. To take an example:
for (int i = 1; i <= 10; i++) {
const int r = rand();
printf("%d\n", r * r / i);
}
the value of "the" const object never changes (in fact any attempt to do
so is either a constraint violation or will produce undefined
behaviour).
I put "the" in quotes because it is the use of phrases like "the const
object r" that leads to confusion. The way to think of this is that a
new object called r appears in every iteration and is destroyed at the
end of the loop body (in each iteration). There are, one after the
other, 10 const objects called r and the value in each and every one
never changes during its lifetime.
People naturally get sloppy and talk about "the object r", but then it
seems as if r can change but it doesn't -- not during the lifetime of
the object.
<snip>
--
Ben.
Keith Thompson
> Keith Thompson wrote:
>> Poster Matt <postermatt@no_spam_for_me.org> writes:
>>> Keith Thompson wrote:
>>>> Poster Matt <postermatt@no_spam_for_me.org> writes:
>>
>>> K&R is somewhat misleading then when it says:
>>>
>>> "The qualifier const can be applied to any variable to specify that
>>> its value will not be changed."
>>
>> How is that unclear? As far as I can tell, it's perfectly accurate;
>> const specifies that the value of the variable (I would have said
>> "object") will not be changed. It doesn't specify that it's a
>> "constant" (where "constant" means roughly that its value can be
>> evaluated at compile time).
>
> I'm not sure I should have said 'misleading', but it certainly does
> not tell the whole story. To my mind the quotation above implies that
> the value specified in the source code will not be changed. So I'd
> never have thought "const int r = rand();" was allowed.
Ok, I see what you mean.
What it really means is that the value will not be changed *once
the object has been initialized*. Once you understand that, it's a
bit difficult to interpret in any other way. (That's why I asked;
the better I understand how beginners can misunderstand things that
seem obvious to me, the better I can explain them.)
[...]
> Thanks again. I've learnt another new thing about C today. I'll get
> there eventually...(I hope).
Me too.
Peter Nilsson
> Poster Matt <postermatt@no_spam_for_me.org> writes:
> > K&R is somewhat misleading then when it says:
> > "The qualifier const can be applied to any variable to
> > specify that its value will not be changed."
>
> How is that unclear?
Well the preface to K&R says...
The book is not an introductory programming manual; it
assumes some familiarity with basic programming concepts...
Most people's familiarity of variables whose 'values will not
be changed,' and especially a CONST keyword, is that of true
constants, not the weaker 'don't write' ones that C employs.
> As far as I can tell, it's perfectly accurate; const
> specifies that the value of the variable (I would have
> said "object") will not be changed. It doesn't specify
> that it's a "constant" (where "constant" means roughly
> that its value can be evaluated at compile time).
Yes, it clearly doesn't say that const is a constant. But
it would have been better if it cleary added that const
_isn't_ a constant.
--
Peter
Poster Matt
> Poster Matt <postermatt@no_spam_for_me.org> writes:
>
>> Keith Thompson wrote:
>>> Poster Matt <postermatt@no_spam_for_me.org> writes:
>>>> Keith Thompson wrote:
>>>>> Poster Matt <postermatt@no_spam_for_me.org> writes:
>>>> K&R is somewhat misleading then when it says:
>>>>
>>>> "The qualifier const can be applied to any variable to specify that
>>>> its value will not be changed."
>>> How is that unclear? As far as I can tell, it's perfectly accurate;
>>> const specifies that the value of the variable (I would have said
>>> "object") will not be changed. It doesn't specify that it's a
>>> "constant" (where "constant" means roughly that its value can be
>>> evaluated at compile time).
>> I'm not sure I should have said 'misleading', but it certainly does
>> not tell the whole story. To my mind the quotation above implies that
>> the value specified in the source code will not be changed.
>
> More than implies -- it says so explicitly and unambiguously!
Not quite, K&R says the "value will not be changed", I said the "value specified
in the source code will not be changed", in other words I mean a fixed constant
value EG. 3.1415, "Keyser Söze", etc., and not some kind of dynamic assignment
like the const int r = rand() example.
>> So I'd
>> never have thought "const int r = rand();" was allowed.
>
> There's really no contradiction. To take an example:
>
> for (int i = 1; i <= 10; i++) {
> const int r = rand();
> printf("%d\n", r * r / i);
> }
>
> the value of "the" const object never changes (in fact any attempt to do
> so is either a constraint violation or will produce undefined
> behaviour).
>
> I put "the" in quotes because it is the use of phrases like "the const
> object r" that leads to confusion. The way to think of this is that a
> new object called r appears in every iteration and is destroyed at the
> end of the loop body (in each iteration). There are, one after the
> other, 10 const objects called r and the value in each and every one
> never changes during its lifetime.
>
> People naturally get sloppy and talk about "the object r", but then it
> seems as if r can change but it doesn't -- not during the lifetime of
> the object.
Ok, got it. :)
Cheers.
Poster Matt
> In article <dTSRn.39999$Cw6.3269@hurricane>,
> Poster Matt <postermatt@no_spam_for_me.org> wrote:
>
>> Re: Macro variable name - the name in my actual code was quite long and
>> descriptive, so I made up a fake name for posting here. eodSize and
>> eodContents
>> were named simply because I had a DVD rental on my desk of a Mel Gibson movie
>> called Edge of Darkness, when the thought entered my mind to make a more
>> concise
>> name for posting, the DVD was in my field of view, hence 'eod'. I didn't
>> capitalize the #define version out of laziness when copying'n'pasting.
>
Actually I'm just his lawyer, Kobayashi. :)
Regards,
Kob
Poster Matt
> Poster Matt <postermatt@no_spam_for_me.org> writes:
>> Keith Thompson wrote:
>>> Poster Matt <postermatt@no_spam_for_me.org> writes:
>>>> Keith Thompson wrote:
>>>>> Poster Matt <postermatt@no_spam_for_me.org> writes:
>>>> K&R is somewhat misleading then when it says:
>>>>
>>>> "The qualifier const can be applied to any variable to specify that
>>>> its value will not be changed."
>>> How is that unclear? As far as I can tell, it's perfectly accurate;
>>> const specifies that the value of the variable (I would have said
>>> "object") will not be changed. It doesn't specify that it's a
>>> "constant" (where "constant" means roughly that its value can be
>>> evaluated at compile time).
>> I'm not sure I should have said 'misleading', but it certainly does
>> not tell the whole story. To my mind the quotation above implies that
>> the value specified in the source code will not be changed. So I'd
>> never have thought "const int r = rand();" was allowed.
>
> Ok, I see what you mean.
>
> What it really means is that the value will not be changed *once
> the object has been initialized*. Once you understand that, it's a
> bit difficult to interpret in any other way. (That's why I asked;
> the better I understand how beginners can misunderstand things that
> seem obvious to me, the better I can explain them.)
That's how I could have answered your earlier question of "How could the
statement in K&R be made clearer?".
K&R amendment (given my lowly level this seems rather arrogant to even attempt,
let alone publicly):
Original: "The qualifier const can be applied to any variable to specify that
its value will not be changed."
Amended: "The qualifier const can be applied to any variable to specify that its
value will not be changed after it has been initialized."
>> Thanks again. I've learnt another new thing about C today. I'll get
>> there eventually...(I hope).
>
> Me too.
Trust me Keith - you're there. :)
Cheers.
Poster Matt
Peter I couldn't have put it clearer myself. In fact I didn't put it clearer.
Thanks for making my point better than I made it. :)
Cheers.
Ben Bacarisse
<snip>
> That's how I could have answered your earlier question of "How could
> the statement in K&R be made clearer?".
>
> K&R amendment (given my lowly level this seems rather arrogant to even
> attempt, let alone publicly):
>
> Original: "The qualifier const can be applied to any variable to
> specify that its value will not be changed."
>
> Amended: "The qualifier const can be applied to any variable to
> specify that its value will not be changed after it has been
> initialized."
This is one of those cases where you risk confusing others who have a
different picture. Some people have the (incorrect) view that a
variable is initialised when it first gets assigned a value. I.e. they
would take your wording as permitting
const int x;
x = 42;
Of course that is not what you intended to suggest, but then K&R did not
intend their words to suggest what you originally took from them!
Finally, your version is unclear in one very technical way. What does
it say about a const variable that is not initialised at all? Automatic
const variables that are defined without an initialiser are not even
implicitly initialised, so presumably their values *can* be changed or
maybe the phrase says nothing at all about such variables?
Simplifying things for the purposes of getting the main ideas across is
an important technique, but I get the feeling that K&R prefer to be as
minimal and as technically accurate as possible. I like that style (I
am always searching for the "K&R of XYZ" when leaning a new language)
but they do run the risk of people reading more into what is written
than is supported by the text or, for that matter, of finding it too
dense.
--
Ben.
Keith Thompson
> Peter Nilsson wrote:
>> Keith Thompson <ks...@mib.org> wrote:
>>> As far as I can tell, it's perfectly accurate; const
>>> specifies that the value of the variable (I would have
>>> said "object") will not be changed. It doesn't specify
>>> that it's a "constant" (where "constant" means roughly
>>> that its value can be evaluated at compile time).
>>
>> Yes, it clearly doesn't say that const is a constant. But
>> it would have been better if it cleary added that const
>> _isn't_ a constant.
>
> Peter I couldn't have put it clearer myself. In fact I didn't put it clearer.
>
> Thanks for making my point better than I made it. :)
Something else that you might run across is that C's use of the words
"const" to mean read-only and "constant" to mean compile-time evaluable
are not universal.
For example, Ada uses the word "constant" to mean about the same
thing that C's "const" means:
R: constant Integer := Random(42);
It uses the word "static" to mean that something can be evaluated at
compile time (whereas C uses "static" to mean -- well, all sorts of
things).
The point is that, if you're going to be working in more than one
language, you need to keep track of the concepts and be prepared to be
flexible about the terminology. (But I recommend being *inflexible*
about the terminology within a given language.)
Poster Matt
Thanks for the advise Keith. I'll bare it in mind.
Cheers.
