Post by jakPost by Barry SchwarzPost by jakOk. Then return to the first question. What information is missing from
the compiler to solve this?
char *Date = "01-01-80";
char *Phrase[] =
{
NULL, /*1*/
Date, /*2*/
NULL, /*3*/
NULL /*4*/
};
...and why does it solve this?
char *DescDate = "Date: ";
char *Date = "01-01-80";
char *CrLf = "\r\n";
char *Text = "Dear friend...";
char **Phrase[] =
{
&DescDate, &Date, &CrLf,
&Text, &CrLf
};
Possibly because the address of a static variable is a compile time
const (note const, not constant) while the value of a static variable
is not.
You would be right if the compiler information was not the same in both
cases. Also at runtime you can change any value in * Phrase [] and in **
Phrase [], too, so why const? I'm afraid it's just a syntactic
imposition. :(
The language standard has to have some consistent definition of what is
or is not a constant expression. It can't just say "anything whose
value the compiler can figure out is a constant expression"; that would
imply that the criteria could change depending on how clever the
compiler happens to be.
In general, the standard doesn't require compilers to perform data flow
analysis.
Let's take a simple example:
char *foo = "hello";
char *bar = foo;
In this case, sure, a compiler *could* perform an analysis that
determines that the value of foo, when it's used in an initializer
for the static object bar, cannot have changed from its initial
value. But although the compiler must generate code that will
cause foo to be properly initialized before entry to main(), it's
not required to remember what that initial value is. It would have
to do so to be able to implement those declarations.
On the other hand, given:
char foo[] = "hello";
char *bar = foo;
the expression `foo` in the initializer yields the address of a
static object, not the (current) value of that object. The compiler
has to be able to generate code that refers to the address of a
static object anyway, so there's no extra burden in requiring it
to treat such an address as a compile-time constant expression.
Given modern optimizing compiler technology, it might be possible to
loosen the rules for constant expressions by requiring *some* data
flow analysis. But (a) that would still impose an extra burden
on small non-optimizing compilers, and (b) defining the exact
new rules in Standardese would be a difficult task (and reaching
agreement on just what those rules should be would be even harder).
A small tweak to the rules, to cover just a case like this one,
might partially avoid those problems, but it's unlikely that it
would be considered worthwhile. The committee isn't going to change
the language to fix a problem that already has a workaround.
--
Keith Thompson (The_Other_Keith) kst-***@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"