[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Now that SCM type is a union...
From: |
rixed |
Subject: |
Re: Now that SCM type is a union... |
Date: |
Sat, 13 Aug 2011 12:40:35 +0200 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
-[ 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).