[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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.