Re: [patch 6/6] scalar-storage-order merge: testsuite

[Eric Botcazou <ebotcazou@adacore.com>]

> 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