[PATCH] tools: avoid redefinition of typedefs

[PATCH] tools: avoid redefinition of typedefs

[Ian Campbell]

When splitting out various functionality from libxc into tools/libs/*
I attempted to make it possible to avoid callers being unnecessarily
exposed to the xentoollog interface by providing a typedef of the
xentoollog_logger handle in each of the headers.

However such typedefs are not allowed in C, instead it is necessary to
forward declare the struct and then use the struct xentoollog_logger
variant in the prototypes.

It appears that older gcc (e.g. 4.4) complains about this issue while
newer ones (e.g. 4.9) are more tolerant unless -pedantic-errors is
used, this was a deliberate change
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=ce3765bf44e49ef0568a1ad4a0b7f807591d6412

As well as tools/libs/* it is also now necessary to give libvchan the
same treatment, since it previously inhereted the typedef via one of
tools/libs/*.

Reported-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/libs/call/include/xencall.h                   |  5 +++--
 tools/libs/evtchn/include/xenevtchn.h               |  5 +++--
 tools/libs/foreignmemory/include/xenforeignmemory.h |  4 ++--
 tools/libs/gnttab/include/xengnttab.h               |  7 ++++---
 tools/libvchan/init.c                               | 13 +++++++++----
 tools/libvchan/libxenvchan.h                        | 10 ++++++++--
 6 files changed, 29 insertions(+), 15 deletions(-)

diff --git a/tools/libs/call/include/xencall.h b/tools/libs/call/include/xencall.h
index 559624a..bafacdd 100644
--- a/tools/libs/call/include/xencall.h
+++ b/tools/libs/call/include/xencall.h
@@ -26,7 +26,7 @@
 #include <stddef.h>
 
 /* Callers who don't care don't need to #include <xentoollog.h> */
-typedef struct xentoollog_logger xentoollog_logger;
+struct xentoollog_logger;
 
 typedef struct xencall_handle xencall_handle;
 
@@ -56,7 +56,8 @@ typedef struct xencall_handle xencall_handle;
  * Calling xencall_close() is the only safe operation on a
  * xencall_handle which has been inherited.
  */
-xencall_handle *xencall_open(xentoollog_logger *logger, unsigned open_flags);
+xencall_handle *xencall_open(struct xentoollog_logger *logger,
+                             unsigned open_flags);
 
 /*
  * Close a handle previously allocated with xencall_open().
diff --git a/tools/libs/evtchn/include/xenevtchn.h b/tools/libs/evtchn/include/xenevtchn.h
index 4d26161..0fa3f84 100644
--- a/tools/libs/evtchn/include/xenevtchn.h
+++ b/tools/libs/evtchn/include/xenevtchn.h
@@ -33,7 +33,7 @@ typedef int evtchn_port_or_error_t;
 typedef struct xenevtchn_handle xenevtchn_handle;
 
 /* Callers who don't care don't need to #include <xentoollog.h> */
-typedef struct xentoollog_logger xentoollog_logger;
+struct xentoollog_logger;
 
 /*
  * EVENT CHANNEL FUNCTIONS
@@ -66,7 +66,8 @@ typedef struct xentoollog_logger xentoollog_logger;
  * xenevtchn_handle which has been inherited.
  */
 /* Currently no flags are defined */
-xenevtchn_handle *xenevtchn_open(xentoollog_logger *logger, unsigned open_flags);
+xenevtchn_handle *xenevtchn_open(struct xentoollog_logger *logger,
+                                 unsigned open_flags);
 
 /*
  * Close a handle previously allocated with xenevtchn_open().
diff --git a/tools/libs/foreignmemory/include/xenforeignmemory.h b/tools/libs/foreignmemory/include/xenforeignmemory.h
index 3724c63..92b9277 100644
--- a/tools/libs/foreignmemory/include/xenforeignmemory.h
+++ b/tools/libs/foreignmemory/include/xenforeignmemory.h
@@ -27,7 +27,7 @@
 #include <xen/xen.h>
 
 /* Callers who don't care don't need to #include <xentoollog.h> */
-typedef struct xentoollog_logger xentoollog_logger;
+struct xentoollog_logger;
 
 typedef struct xenforeignmemory_handle xenforeignmemory_handle;
 
@@ -55,7 +55,7 @@ typedef struct xenforeignmemory_handle xenforeignmemory_handle;
  * Calling xenforeignmemory_close() is the only safe operation on a
  * xenforeignmemory_handle which has been inherited.
  */
-xenforeignmemory_handle *xenforeignmemory_open(xentoollog_logger *logger,
+xenforeignmemory_handle *xenforeignmemory_open(struct xentoollog_logger *logger,
                                                unsigned open_flags);
 
 /*
diff --git a/tools/libs/gnttab/include/xengnttab.h b/tools/libs/gnttab/include/xengnttab.h
index 1ca1e70..0431dcf 100644
--- a/tools/libs/gnttab/include/xengnttab.h
+++ b/tools/libs/gnttab/include/xengnttab.h
@@ -28,7 +28,7 @@
 #include <xen/event_channel.h>
 
 /* Callers who don't care don't need to #include <xentoollog.h> */
-typedef struct xentoollog_logger xentoollog_logger;
+struct xentoollog_logger;
 
 /*
  * PRODUCING AND CONSUMING GRANT REFERENCES
@@ -132,7 +132,8 @@ typedef struct xengntdev_handle xengnttab_handle;
  * xengnttab_handle which has been inherited. xengnttab_unmap() must
  * not be called under such circumstances.
  */
-xengnttab_handle *xengnttab_open(xentoollog_logger *logger, unsigned open_flags);
+xengnttab_handle *xengnttab_open(struct xentoollog_logger *logger,
+                                 unsigned open_flags);
 
 /*
  * Close a handle previously allocated with xengnttab_open(),
@@ -287,7 +288,7 @@ typedef struct xengntdev_handle xengntshr_handle;
  * Calling xengntshr_close() is the only safe operation on a
  * xengntshr_handle which has been inherited.
  */
-xengntshr_handle *xengntshr_open(xentoollog_logger *logger,
+xengntshr_handle *xengntshr_open(struct xentoollog_logger *logger,
                                  unsigned open_flags);
 
 /*
diff --git a/tools/libvchan/init.c b/tools/libvchan/init.c
index 91531b9..cadd12c 100644
--- a/tools/libvchan/init.c
+++ b/tools/libvchan/init.c
@@ -212,7 +212,8 @@ static int init_gnt_cli(struct libxenvchan *ctrl, int domain, uint32_t ring_ref)
 	goto out;
 }
 
-static int init_evt_srv(struct libxenvchan *ctrl, int domain, xentoollog_logger *logger)
+static int init_evt_srv(struct libxenvchan *ctrl, int domain,
+                        struct xentoollog_logger *logger)
 {
 	evtchn_port_or_error_t port;
 
@@ -293,7 +294,9 @@ static int min_order(size_t siz)
 	return rv;
 }
 
-struct libxenvchan *libxenvchan_server_init(xentoollog_logger *logger, int domain, const char* xs_path, size_t left_min, size_t right_min)
+struct libxenvchan *libxenvchan_server_init(struct xentoollog_logger *logger,
+                                            int domain, const char* xs_path,
+                                            size_t left_min, size_t right_min)
 {
 	struct libxenvchan *ctrl;
 	int ring_ref;
@@ -342,7 +345,8 @@ out:
 	return 0;
 }
 
-static int init_evt_cli(struct libxenvchan *ctrl, int domain, xentoollog_logger *logger)
+static int init_evt_cli(struct libxenvchan *ctrl, int domain,
+                        struct xentoollog_logger *logger)
 {
 	evtchn_port_or_error_t port;
 
@@ -372,7 +376,8 @@ fail:
 }
 
 
-struct libxenvchan *libxenvchan_client_init(xentoollog_logger *logger, int domain, const char* xs_path)
+struct libxenvchan *libxenvchan_client_init(struct xentoollog_logger *logger,
+                                            int domain, const char* xs_path)
 {
 	struct libxenvchan *ctrl = malloc(sizeof(struct libxenvchan));
 	struct xs_handle *xs = NULL;
diff --git a/tools/libvchan/libxenvchan.h b/tools/libvchan/libxenvchan.h
index 341c375..2adbdfe 100644
--- a/tools/libvchan/libxenvchan.h
+++ b/tools/libvchan/libxenvchan.h
@@ -47,6 +47,9 @@
 #include <xenevtchn.h>
 #include <xengnttab.h>
 
+/* Callers who don't care don't need to #include <xentoollog.h> */
+struct xentoollog_logger;
+
 struct libxenvchan_ring {
 	/* Pointer into the shared page. Offsets into buffer. */
 	struct ring_shared* shr;
@@ -93,7 +96,9 @@ struct libxenvchan {
  * @param recv_min The minimum size (in bytes) of the receive ring (right)
  * @return The structure, or NULL in case of an error
  */
-struct libxenvchan *libxenvchan_server_init(xentoollog_logger *logger, int domain, const char* xs_path, size_t read_min, size_t write_min);
+struct libxenvchan *libxenvchan_server_init(struct xentoollog_logger *logger,
+                                            int domain, const char* xs_path,
+                                            size_t read_min, size_t write_min);
 /**
  * Connect to an existing vchan. Note: you can reconnect to an existing vchan
  * safely, however no locking is performed, so you must prevent multiple clients
@@ -104,7 +109,8 @@ struct libxenvchan *libxenvchan_server_init(xentoollog_logger *logger, int domai
  * @param xs_path Base xenstore path for storing ring/event data
  * @return The structure, or NULL in case of an error
  */
-struct libxenvchan *libxenvchan_client_init(xentoollog_logger *logger, int domain, const char* xs_path);
+struct libxenvchan *libxenvchan_client_init(struct xentoollog_logger *logger,
+                                            int domain, const char* xs_path);
 /**
  * Close a vchan. This deallocates the vchan and attempts to free its
  * resources. The other side is notified of the close, but can still read any
-- 
2.6.1

Re: [PATCH] tools: avoid redefinition of typedefs

[Ian Jackson]

Ian Campbell writes ("[PATCH] tools: avoid redefinition of typedefs"):
> When splitting out various functionality from libxc into tools/libs/*
> I attempted to make it possible to avoid callers being unnecessarily
> exposed to the xentoollog interface by providing a typedef of the
> xentoollog_logger handle in each of the headers.

Thanks.  Sorry for not spotting this earlier.

> Reported-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

Re: [PATCH] tools: avoid redefinition of typedefs

[Olaf Hering]

On Mon, Jan 25, Ian Campbell wrote:

> When splitting out various functionality from libxc into tools/libs/*
> I attempted to make it possible to avoid callers being unnecessarily
> exposed to the xentoollog interface by providing a typedef of the
> xentoollog_logger handle in each of the headers.

Perhaps you already have another change in the queue. staging still
fails for me with evtchn_port_or_error_t xenevtchn_handle, like:

[  130s] In file included from xc_private.h:35,
[  130s]                  from xc_suspend.c:21:
[  130s] ./include/xenctrl.h:1080: error: redefinition of typedef 'evtchn_port_or_error_t'
[  130s] /usr/src/packages/BUILD/xen-4.7.20160125T154552.84e0616/non-dbg/tools/libxc/../../tools/libs/evtchn/include/xenevtchn.h:31: error: previous declaration of 'evtchn_port_or_error_t' was here
[  130s] In file included from xc_suspend.c:22:
[  130s] ./include/xenguest.h:41: error: redefinition of typedef 'xenevtchn_handle'
[  130s] /usr/src/packages/BUILD/xen-4.7.20160125T154552.84e0616/non-dbg/tools/libxc/../../tools/libs/evtchn/include/xenevtchn.h:33: error: previous declaration of 'xenevtchn_handle' was here

Olaf

Re: [PATCH] tools: avoid redefinition of typedefs

[Ian Campbell]

On Mon, 2016-01-25 at 17:24 +0100, Olaf Hering wrote:
> On Mon, Jan 25, Ian Campbell wrote:
> 
> > When splitting out various functionality from libxc into tools/libs/*
> > I attempted to make it possible to avoid callers being unnecessarily
> > exposed to the xentoollog interface by providing a typedef of the
> > xentoollog_logger handle in each of the headers.
> 
> Perhaps you already have another change in the queue. staging still
> fails for me with evtchn_port_or_error_t xenevtchn_handle, like:

I'm afraid not.

I'll take a look.


> 
> [  130s] In file included from xc_private.h:35,
> [  130s]                  from xc_suspend.c:21:
> [  130s] ./include/xenctrl.h:1080: error: redefinition of typedef
> 'evtchn_port_or_error_t'
> [  130s] /usr/src/packages/BUILD/xen-4.7.20160125T154552.84e0616/non-
> dbg/tools/libxc/../../tools/libs/evtchn/include/xenevtchn.h:31: error:
> previous declaration of 'evtchn_port_or_error_t' was here
> [  130s] In file included from xc_suspend.c:22:
> [  130s] ./include/xenguest.h:41: error: redefinition of typedef
> 'xenevtchn_handle'
> [  130s] /usr/src/packages/BUILD/xen-4.7.20160125T154552.84e0616/non-
> dbg/tools/libxc/../../tools/libs/evtchn/include/xenevtchn.h:33: error:
> previous declaration of 'xenevtchn_handle' was here
> 
> Olaf

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

Re: [PATCH] tools: avoid redefinition of typedefs

[Ian Campbell]

On Mon, 2016-01-25 at 16:37 +0000, Ian Campbell wrote:
> On Mon, 2016-01-25 at 17:24 +0100, Olaf Hering wrote:
> > On Mon, Jan 25, Ian Campbell wrote:
> > 
> > > When splitting out various functionality from libxc into tools/libs/*
> > > I attempted to make it possible to avoid callers being unnecessarily
> > > exposed to the xentoollog interface by providing a typedef of the
> > > xentoollog_logger handle in each of the headers.
> > 
> > Perhaps you already have another change in the queue. staging still
> > fails for me with evtchn_port_or_error_t xenevtchn_handle, like:
> 
> I'm afraid not.
> 
> I'll take a look.

I managed to reproduce with gcc-4.4 on my workstation, except I had to
disable the Python bits (because it apparently hardcodes CFLAGS from the
default compiler but still obey's $(CC) or something).

With that I've sent two more fixes for issues in this area. 

Boris, copying you since you are suffering from these sorts of issues too.

> 
> 
> > 
> > [  130s] In file included from xc_private.h:35,
> > [  130s]                  from xc_suspend.c:21:
> > [  130s] ./include/xenctrl.h:1080: error: redefinition of typedef
> > 'evtchn_port_or_error_t'
> > [  130s] /usr/src/packages/BUILD/xen-4.7.20160125T154552.84e0616/non-
> > dbg/tools/libxc/../../tools/libs/evtchn/include/xenevtchn.h:31: error:
> > previous declaration of 'evtchn_port_or_error_t' was here
> > [  130s] In file included from xc_suspend.c:22:
> > [  130s] ./include/xenguest.h:41: error: redefinition of typedef
> > 'xenevtchn_handle'
> > [  130s] /usr/src/packages/BUILD/xen-4.7.20160125T154552.84e0616/non-
> > dbg/tools/libxc/../../tools/libs/evtchn/include/xenevtchn.h:33: error:
> > previous declaration of 'xenevtchn_handle' was here
> > 
> > Olaf
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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