Re: Now that SCM type is a union...

[rixed]

-[ Sat, Aug 13, 2011 at 01:26:03AM -0400, Ken Raeburn ]----
> ("Is for some reason invalid" is not very descriptive; please include 
> specific compiler messages.)

Sorry ; the specific error message was, you guesssed it right:
"initializer element is not constant".

> That syntax -- the parenthesized type followed by a list of initializers in 
> braces -- is called a "compound literal" (technically not a cast expression) 
> and was added in C99.  The value of a compound literal is an anonymous object 
> with a value given by the initializer elements.  (It's an lvalue, and can 
> even have its address taken.)  That means it's not a "constant expression" 
> and cannot be used for static initialization, under C99 rules.

Yes thank you for clarifying this. In this context of initializing a
global variable my brain failed to recognize a compound literal.
It all make sense now, both why it's used and why gcc is complaining.
Now it seams indeed wrong to use an anonymous lvalue as an initializer.

> The GCC documentation says that a GCC extension permits such initialization.

Even if it was the case, would it be a good idea for header files that
are supposed to be included in user programs to rely on a gcc extension ?

> From that I'd kind of expect it to work in gnu89 or gnu99 modes, and maybe 
> not c89, but apparently that's not how they did it...

It actualy works with gnu89 or c89, but neither gnu99 nor c99 :

---[ foobar.c ]---

struct foo { int a; };
struct foo bar = (struct foo){ 1 };

---[ /foobar.c ]---

make foobar.o CFLAGS="-std=gnu99"
foobar.c:2:26: error: initializer element is not constant

same goes for c99 ; while:

make foobar.o CFLAGS="-std=c89"

works.

> Have an initialization function which stuffs SCM_UNSPECIFIED into a bunch of 
> uninitialized SCM variables before making them accessible from other code?  
> Yeah, it's kind of unfortunate.

Especially unfortunate if one do not want to rely on gcc specific
constructor to initialize it automagically ; and it makes programs
that were working with former versions of guile fails to compile which
is not so nice.

> Maybe we need a separate set of macros for static initialization using 
> SCM_UNDEFINED, SCM_BOOL_F, and friends?

I'd like it. Or maybe instead of checking for a PREHISTORIC_COMPILER
the header files may check for actual compiler settings (ie. if C99
conformance is required then don't use the union) ; if the underlying
encoding of the alternative is the same, of course.

> It looks like Guile is compiled in the default (gnu89?) mode, not C99.  It 
> has a few places where static variables are initialized using SCM_BOOL_F, 
> which will have the same problem.

Yes, whenever c99 becomes the default (it's only 12 years old now).