From mboxrd@z Thu Jan  1 00:00:00 1970
From: PUCCETTI Armand <armand.puccetti@cea.fr>
Subject: Re: non-ANSI Unions
Date: Fri, 23 Mar 2007 17:00:31 +0100
Message-ID: <4603F99F.5040100@cea.fr>
References: <4603F338.6050507@cea.fr> <4603F533.5070003@us.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Return-path: <xen-devel-bounces@lists.xensource.com>
In-Reply-To: <4603F533.5070003@us.ibm.com>
List-Unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com
To: Anthony Liguori <aliguori@us.ibm.com>
Cc: xen-devel@lists.xensource.com
List-Id: xen-devel@lists.xenproject.org

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

Anthony Liguori a =E9crit :
> 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=20
> much preferred to using a named union for the syntactical convenience=20
> of writing:
>
> page_info.list
>
> vs writing:
>
> page_info.u.list
>
> Also, this is not the only C extension that Xen utilizes.  If your=20
> analysis tool doesn't support the various GCC extensions, then it's=20
> 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=20
>> 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=20
>> 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=20
>> comply with the standard
>> (and therefore with analysis tools too) ?
>>
>> Armand
>
>