non-ANSI Unions

non-ANSI Unions

[PUCCETTI Armand]

Many "unions' are present in the code, but are non-ANSI!

For instance, I see:

struct page_info
{
    /* Each frame can be threaded onto a doubly-linked list. */
    union {
        struct list_head list;
        /* Shadow uses this field as an up-pointer in lower-level shadows */
        paddr_t up;
    };
    /* Reference count and various PGC_xxx flags and fields. */
    u32 count_info;
...}

which should be written properly:

struct page_info
{
    /* Each frame can be threaded onto a doubly-linked list. */
    union {
        struct list_head list;
        /* Shadow uses this field as an up-pointer in lower-level shadows */
        paddr_t up;
    } foo;

    /* Reference count and various PGC_xxx flags and fields. */
    u32 count_info;
...}

Is there any good reason to do so? Is it possible to change that, to 
comply with the standard
(and therefore with analysis tools too) ?

Armand

Re: non-ANSI Unions

[Anthony Liguori]

PUCCETTI Armand wrote:
> Many "unions' are present in the code, but are non-ANSI!

Anonymous unions/structs are a rather common C extension.  They are much 
preferred to using a named union for the syntactical convenience of writing:

page_info.list

vs writing:

page_info.u.list

Also, this is not the only C extension that Xen utilizes.  If your 
analysis tool doesn't support the various GCC extensions, then it's not 
going to be much help.

Regards,

Anthony Liguori

> For instance, I see:
> 
> struct page_info
> {
>    /* Each frame can be threaded onto a doubly-linked list. */
>    union {
>        struct list_head list;
>        /* Shadow uses this field as an up-pointer in lower-level shadows */
>        paddr_t up;
>    };
>    /* Reference count and various PGC_xxx flags and fields. */
>    u32 count_info;
> ...}
> 
> which should be written properly:
> 
> struct page_info
> {
>    /* Each frame can be threaded onto a doubly-linked list. */
>    union {
>        struct list_head list;
>        /* Shadow uses this field as an up-pointer in lower-level shadows */
>        paddr_t up;
>    } foo;
> 
>    /* Reference count and various PGC_xxx flags and fields. */
>    u32 count_info;
> ...}
> 
> Is there any good reason to do so? Is it possible to change that, to 
> comply with the standard
> (and therefore with analysis tools too) ?
> 
> Armand

Re: non-ANSI Unions

[PUCCETTI Armand]

Sorry, it was an err in the tool. Such unions are now understood properly.

Anthony Liguori a écrit :
> PUCCETTI Armand wrote:
>> Many "unions' are present in the code, but are non-ANSI!
>
> Anonymous unions/structs are a rather common C extension.  They are 
> much preferred to using a named union for the syntactical convenience 
> of writing:
>
> page_info.list
>
> vs writing:
>
> page_info.u.list
>
> Also, this is not the only C extension that Xen utilizes.  If your 
> analysis tool doesn't support the various GCC extensions, then it's 
> not going to be much help.
>
> Regards,
>
> Anthony Liguori
>
>> For instance, I see:
>>
>> struct page_info
>> {
>>    /* Each frame can be threaded onto a doubly-linked list. */
>>    union {
>>        struct list_head list;
>>        /* Shadow uses this field as an up-pointer in lower-level 
>> shadows */
>>        paddr_t up;
>>    };
>>    /* Reference count and various PGC_xxx flags and fields. */
>>    u32 count_info;
>> ...}
>>
>> which should be written properly:
>>
>> struct page_info
>> {
>>    /* Each frame can be threaded onto a doubly-linked list. */
>>    union {
>>        struct list_head list;
>>        /* Shadow uses this field as an up-pointer in lower-level 
>> shadows */
>>        paddr_t up;
>>    } foo;
>>
>>    /* Reference count and various PGC_xxx flags and fields. */
>>    u32 count_info;
>> ...}
>>
>> Is there any good reason to do so? Is it possible to change that, to 
>> comply with the standard
>> (and therefore with analysis tools too) ?
>>
>> Armand
>
>