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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel