On Aug 13, 2011, at 08:23, Andy Wingo wrote:
> I only have a draft copy of C99, from 7 September 2007, but it does
> permit constant expressions to appear outside function bodies. How
> could that happen except for in initializers? I do see the language in
> the GCC docs though; it's confusing. I was under the impression that
> they would be constant expressions, but perhaps I was mistaken.
It is confusing. There's an example in the final spec which I think indicates
what's happening:
int *p = (int []){2, 4}; // definition at file scope, outside any fn
The compound literal produces an anonymous object (with static storage
duration, in this case) of type "int[2]"; in this context, its initialization
elements have to be constants. Through the standard conversion of array to
pointer-to-element, the value of this expression becomes an "int *" which is
used to initialize p (allowed because the object has static storage duration
and thus its address is a constant).
When array/pointer conversions aren't involved, you might assume you could just
initialize a variable statically, but since the compound literal creates an
object, an lvalue, it's more like saying:
static int anon = 3; // "anonymous" obj with constant initializer
int x = anon; // not allowed in C99
You could make "anon" const, but it wouldn't change anything, under C99 rules.
Note, too, that the unnamed object created doesn't need to be "const" --
changing p[0] above is perfectly valid. Though if you use const in the type,
then the compiler is permitted to combine identical values and store only one
copy.
Also:
* We should expect some Guile applications to be in C++. What versions of the
C++ spec should Guile support?
* Shouldn't there be testing to catch this? (C89 mode, C99 mode, different
C++ specs, enabling various compiler warnings -- for whatever compiler is in
use -- and make them fatal, any interesting ways one might want to use libguile
in an application that might stress compatibility issues.) I mean automated
testing, not just Cedric. :-)
> I will take a look at this issue soonish, but your help (and Cedric's)
> in debugging it is most appreciated :) I would love to keep the union
> as the "normal" SCM definition, but that might not be possible.
Regardless of the validity, there are popular compilers out there now which do
not support this, when used in modes people may need or want to use. The
installed headers need to adhere to higher standards in terms of portability
problems and warnings than the library source, where we can dictate some of the
compiler options.
Ken
