diff mbox

[Xen-devel,v5,2/8] tools/libxc: pull min/max_t into xc_private.h

Message ID 1404907666-8594-2-git-send-email-ian.campbell@citrix.com
State Accepted
Commit 911a3042f3e80c74181361d1e8f11d386c100847
Headers show

Commit Message

Ian Campbell July 9, 2014, 12:07 p.m. UTC
There are generally useful.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
---
v2: New patch.
---
 tools/libxc/xc_dom_decompress_unsafe_xz.c |    5 -----
 tools/libxc/xc_private.h                  |    5 +++++
 2 files changed, 5 insertions(+), 5 deletions(-)

Comments

Ian Jackson July 10, 2014, 11:01 a.m. UTC | #1
Ian Campbell writes ("[PATCH v5 2/8] tools/libxc: pull min/max_t into xc_private.h"):
> There are generally useful.

Sorry for not spotting this but: names matching "*_t" are by the C
spec "reserved for the implementation".  This is not a problem in the
hypervisor because that is compiled without the system headrs.

In practice what this means is that it is possible that porting the
tools to a new platform might involve renaming these macros.  So we
don't need to fix it right now unless we really feel like it.

But we mustn't let the scope of these increase to include guest-side
code.

(Also "min_t" is a very funny name for a function macro like this one.
To me it implies a type.)

Ian.
Ian Campbell July 10, 2014, 11:08 a.m. UTC | #2
On Thu, 2014-07-10 at 12:01 +0100, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH v5 2/8] tools/libxc: pull min/max_t into xc_private.h"):
> > There are generally useful.
> 
> Sorry for not spotting this but: names matching "*_t" are by the C
> spec "reserved for the implementation".  This is not a problem in the
> hypervisor because that is compiled without the system headrs.

Oh damn, yes of course.

> In practice what this means is that it is possible that porting the
> tools to a new platform might involve renaming these macros.  So we
> don't need to fix it right now unless we really feel like it.
> 
> But we mustn't let the scope of these increase to include guest-side
> code.

I don't think there is any danger of that, there's no reason at all for
this to be in e.g. xen/include/public.

> (Also "min_t" is a very funny name for a function macro like this one.
> To me it implies a type.)

It's the _typed version of min I suppose, I think we've inherited this
all the way from Linux without really considering the name...

Ian.
diff mbox

Patch

diff --git a/tools/libxc/xc_dom_decompress_unsafe_xz.c b/tools/libxc/xc_dom_decompress_unsafe_xz.c
index 2a32d40..6be1f89 100644
--- a/tools/libxc/xc_dom_decompress_unsafe_xz.c
+++ b/tools/libxc/xc_dom_decompress_unsafe_xz.c
@@ -40,11 +40,6 @@  static inline u32 le32_to_cpup(const u32 *p)
         (void) (&_x == &_y);            \
         _x < _y ? _x : _y; })
 
-#define min_t(type,x,y) \
-        ({ type __x = (x); type __y = (y); __x < __y ? __x: __y; })
-#define max_t(type,x,y) \
-        ({ type __x = (x); type __y = (y); __x > __y ? __x: __y; })
-
 #define __force
 #define always_inline
 
diff --git a/tools/libxc/xc_private.h b/tools/libxc/xc_private.h
index 6cc0f2b..c240a7c 100644
--- a/tools/libxc/xc_private.h
+++ b/tools/libxc/xc_private.h
@@ -349,6 +349,11 @@  int xc_ffs16(uint16_t x);
 int xc_ffs32(uint32_t x);
 int xc_ffs64(uint64_t x);
 
+#define min_t(type,x,y) \
+        ({ type __x = (x); type __y = (y); __x < __y ? __x: __y; })
+#define max_t(type,x,y) \
+        ({ type __x = (x); type __y = (y); __x > __y ? __x: __y; })
+
 #define DOMPRINTF(fmt, args...) xc_dom_printf(dom->xch, fmt, ## args)
 #define DOMPRINTF_CALLED(xch) xc_dom_printf((xch), "%s: called", __FUNCTION__)