bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-gnulib] addition: minmax.h


From: Bruno Haible
Subject: Re: [Bug-gnulib] addition: minmax.h
Date: Fri, 24 Jan 2003 16:27:10 +0100 (CET)

Paul Eggert writes:

> Unfortunately with minmax.h you are forced to back to those times,
> because random system headers can and do define MIN and MAX macros
> unconditionally, and code must therefore include all system headers
> before including minmax.h.

Indeed many system headers define MIN and MAX, argh. Fortunately 2/3rd
of them are protected through #ifndef.

#ifndef protected definitions:

  Solaris:
  Mrm/Mrm.h:#define MAX(x,y)      ((x) > (y) ? (x) : (y))
  Xm/XmP.h:#define MAX(x,y)       ((x) > (y) ? (x) : (y))
  inet/common.h:#define   MAX(x1, x2)     ((x1) >= (x2) ? (x1) : (x2))
  sys/sysmacros.h:#define MAX(a, b)       ((a) < (b) ? (b) : (a))

  AIX:
  Xm/RegionI.h:#define MAX(a,b) (((a) > (b)) ? (a) : (b))
  Xm/XmI.h:#define MAX(x,y)       ((x) > (y) ? (x) : (y))
  Xm/XmP.h:#define MAX(x,y)       ((x) > (y) ? (x) : (y))
  sys/ltypes.h:#define MAX(X, Y) ((X) < (Y) ? (Y) : (X))
  sys/param.h:#define     MAX(a,b) (((a)>(b))?(a):(b))

  IRIX:
  Mrm/Mrm.h:#define MAX(x,y)      ((x) > (y) ? (x) : (y))
  Sgm/GraphP.h:#define MAX(a,b)        ((a) > (b) ? (a) : (b))
  Xm/XmP.h:#define MAX(x,y)       ((x) > (y) ? (x) : (y))
  cmplrs/dec.h:#define _MAX(A,B)        ((A) > (B) ? (A) : (B))
  gl/rect.h:#define MAX(a, b)     (((a) > (b)) ? (a) : (b))
  rsvp/rsvp_mac.h:#define MAX(a,b) (((a)>(b))?(a):(b))

  HP-UX:
  X11/region.h:#define MAX(a,b) (((a) > (b)) ? (a) : (b))
  Xm/XmP.h:#define MAX(x,y)       ((x) > (y) ? (x) : (y))
  dce/dce.h:#  define MAX(x, y)         ((x) > (y) ? (x) : (y))

  OSF/1:
  Xm/XmP.h:#define MAX(x,y)       ((x) > (y) ? (x) : (y))
  cmplrs/dec.h:#define _MAX(A,B)        ((A) > (B) ? (A) : (B))

  Linux:
  linux/efs_fs.h:#define MAX(a, b) (((a) > (b)) ? (a) : (b))

Unprotected definitions:

  IRIX:
  gl/port.h:#define MAX(a, b)     (((a) > (b)) ? (a) : (b))
  netman/macros.h:#define MAX(a,b) (((a)>(b))?(a):(b))
  sys/kdsp_kern.h:#define MAX(a,b) (((a) > (b)) ? (a) : (b))
  sys/param.h:#define MAX(a,b) (((a)>(b))?(a):(b))

  HP-UX:
  sys/param.h:#define     MAX(a,b) (((a)>(b))?(a):(b))

  OSF/1:
  PEX/PEXmacros.h:#define MAX( _a, _b ) ( (_a) > (_b) ? (_a) : (_b) )
  sys/param.h:#define MAX(a,b) (((a)>(b))?(a):(b))

  Linux:
  glib.h:#define MAX(a, b)  (((a) > (b)) ? (a) : (b))
  linux/isdn.h:#define MAX(a,b) ((a>b)?a:b)
  sys/param.h:#define     MAX(a,b) (((a)>(b))?(a):(b))


> Since there's no way around the problem in
> general, we might as well warn people about it

OK, I'm adding a comment about it.

> > The point of the __extension__ is to let gcc make optimal code.
> 
> Does it really have an beneficial effect in the code that GCC
> generates for your application?  I can see where it might make a
> difference in the Linux kernel, which often uses volatile and the like
> and which assumes GCC, but I don't see where it will make a difference
> in ordinary applications that must be portable to non-GCC compilers.

You can change minmax.h to use the simple definition always. For GNU
gettext, the compiler's common subexpression elimination pass will
optimize all occurrences of MIN and MAX sufficiently well. Therefore no
objection from me.

Bruno




reply via email to

[Prev in Thread] Current Thread [Next in Thread]