Re: [Xen-devel] [PATCH XEN v8 02/29] tools: Refactor /dev/xen/evtchn wrappers into libxenevtchn.

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 25/01/16 14:47, Ian Campbell wrote:
> On Mon, 2016-01-25 at 14:35 +0000, Ian Jackson wrote:
>> Ian Campbell writes ("Re: [Xen-devel] [PATCH XEN v8 02/29] tools:
>> Refactor /dev/xen/evtchn wrappers into libxenevtchn."):
>>> Various of the tools/libs/*/include/*.h have a
>>>
>>>     /* Callers who don't care don't need to #include <xentoollog.h> */
>>>     typedef struct xentoollog_logger xentoollog_logger;
>>>
>>> but since that typedef matches in all cases I think it is allowed to be
>>> repeated like this, isn't it?
>> No, I'm afraid not.
> :-/
>
>>   It is permitted to repeatedly mention `struct
>> xentoollog_logger', but the typedef must only occur once in any
>> translation unit.
> For some reason I thought the typedef's could be repeated so long as they
> were identical.
>
> Seems at least Debian's gcc tolerates such things (which makes me wonder
> how many more instances of this might have snuck in, I guess folks like
> Boris would have spotted them pretty quick).
>
>> If it is desirable to let callers avoid including xentoollog.h, then
>> all those headers need to say:
>>
>>   struct xentoollog_logger;
>>   int some_function(..., struct xentoollog_logger *lg, ...);
>>
>> So in your patches something like:
>>
>>   struct xentoollog_logger;
>>
>>   xenevtchn_handle *xenevtchn_open(struct xentoollog_logger *logger,
>>                                    unsigned open_flags);
> I'll do something like this for tools/libs/*/include.
>
> FYI the underlying patches are all in since Friday.

How about doing the header strictness check on all headers at one?  If
repeating typedefs is a gccism, that should catch it.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel