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

[Paul Eggert]

Bruno Haible <address@hidden> writes:

> I don't want to go back to the times (around 1990) where users had to
> remember ordering restrictions like "you have to #include
> <sys/select.h> before <sys/types.h> not afterwards because of such and
> such OS".

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.  Since there's no way around the problem in
general, we might as well warn people about it rather than give them a
false sense of security by solving it only for <stdlib.h>.

Another workaround would be to rename MIN and MAX, but I'm loath to do
that....

> Currently gnulib has no #include ordering restrictions - minmax.h
> would be the first one.

No, actually, gnulib has lots of #include ordering restrictions.
For example, <dirname.h> assumes that you've declared size_t.
These restrictions have not been a problem in practice.

> > A minor nit: the recommended GNU coding style is to put a
> > space after the commas.

> I avoid to do this because then it is very tempting to use the GNU
> coding style for the entire
>          #  define MAX (a, b) ...

Let's avoid that temptation.  :-)

Seriously, though, the recommended style is to put spaces after the
commas, even in macro definitions; it's what's almost invariably used
in GNU applications.  I'd rather that we stick to that style rather
than invent a new one.  (Personally I prefer other styles to the GNU
style, but there are real advantages to consistency.)

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