> It appears that all the C tests check the specific syntactic form
> 'struct __attr_sso__ foo {...};'
>
> What is the impact of changing the location of __attr_sso__? Eg:
>
> struct foo {...} __attr_sso__;
None. What impact could it have?
> (Note that alignment attributes can have significant impact depending on
> where in the syntax the attribute is placed (I'm expecting this will be
> true here as well).
Ouch. This sounds like a bug to me.
> What about with typedefs?
It's ignored (with a warning) on typedefs.
> Can I apply the attribute to a previously laid out struct?
Example? Is that supported for other type attributes?
> Can I apply it to individual fields in the struct, eg:
>
> struct bar
> {
> int a;
> int __attr_sso__ b;
> };
No, but you can do this:
struct bar
{
int a;
struct __attr_sso__ foo
{
int b;
} s;
};
> Can I modify an existing struct to create an opposite endian variant? Eg.
>
> struct bar
> {
> int a;
> };
>
> struct wibble
> {
> struct __attr_sso__ bar a;
> };
The compiler accepts it, but apparently discards the attribute silently, which
looks like a bug to me. Let me investigate.
> Assuming mixed fields in a struct are possible, can it be applied to
> individual bitfields? What is the impact on mixing big and little
> endian bitfields in the same structure.
Mixing bitfields with different endianness is simply not possible, they would
be non-contiguous in one of the orders. The endianness can only be flipped on
storage unit boundaries, which is automatically enforced in the C family of
languages by the aggregate type constraint (but not in Ada, so we have a
specific check to that effect in the Ada compiler).
--
Eric Botcazou
