[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH XEN v8 02/29] tools: Refactor /dev/xen/evtchn wrappers into libxenevtchn.
On 01/25/2016 09:35 AM, 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. 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); The separate `struct xentoollog_logger;' is needed because otherwise the `struct xentoollog_logger *logger' in the formal parameters of xenevtchn_open is a declaration, rather than a reference to a previously-declared thing, and if it is a declaration its scope is only the contained function prototype, so other mentions of `struct xentoollog_logger' are treated as references to a different type. This is, of course, insane. (I was just about to respond to IanC's earlier message)It builds on my desktop (gcc 4.9.2) but not on an older setup (4.4.7). BTW, I should have explicitly said so: I haven't bisected to this commit --- it just looked like this ould be the culprit. -boris _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |