Re: Type macros and friends

[Marcus Brinkmann]

At Tue, 15 Feb 2005 00:15:45 +0100,
Johan Rydberg wrote:
> 
> Hi,
> 
> I was browsing through the libl4 headers earlier today, and got to
> thinking about constructs like the following:
> 
> typedef _L4_RAW (_L4_api_version_t, _L4_STRUCT1 ({
>   _L4_BITFIELD4
>     (_L4_word_t,
>      _L4_BITFIELD (__pad1, 16),
> 
>      /* The subversion or revision.  */
>      _L4_BITFIELD (subversion, 8),
> 
>      /* The interface version.  */
>      _L4_BITFIELD (version, 8),
>                   
>      _L4_BITFIELD_64 (__pad2, 32));
> })) __L4_api_version_t;
> 
> Which results more or less in a union that looks like:
> 
>   union foo
>   {
>     int raw;
>     struct {
>       int x : 16;
>       int y : 16;
>     };
>   };
> 
> This make "x" and "y" visible in the "foo" scope.  For example:
> 
>   union foo foo = { .raw = X };
>   printf ("%x\n", foo.x);
> 
> All good, but what if you want to declare a "foo" staticly?  Like this:
> 
>   union foo bar =
>   {
>     .x = 10, .y = 20
>   };
> 
> In this case "x" and "y" are _NOT_ available in the "foo" scope.  This
> is extremely limiting, from my point of view.  I've tried a gazillion
> combinations to try to make a static construct, but have yet to succeed.  
> 
>   bar.c:13: unknown field `x' specified in initializer
> 
> Anyone got any ideas how a static construct can be created in this
> case?

This is a known bug.  I reported it myself: 

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10676

Frankly, I think it's better avoided to access the struct members at
all.  Better use accessor functions and constructors.

Do we need static initialization?  All constructors will evaluate to
constants if you use constant arguments, as all the code is inlined.
And the data types are one or two words at most.  So the need seems to
be miniscule.

I am open to suggestions how to extend libl4 to make static
initialization possible if it seems useful to you.  Using macros, for
example, which know the order in which the fields appear (and thus
don't need to name them).

Thanks,
Marcus