> > +#define MINIMUM(a, b) (((a) < (b)) ? (a) : (b))
>
> you don't want to use the MIN from <sys/param.h>? many files in libc
> already do. (though admittedly fvwrite.c defines its own, but that
> seems like a bug.)
I guess you haven't observed the commits of the last week...
I am certain you know <sys/param.h> creates much namespace pollution
on all systems. This is largely unavoidable since this is a poorly
specified legacy header. Recently I went through efforts to limit the
pollution, and to limit pulling in the pollution.
The base system now uses POSIX <limits.h> rather than <sys/param.h>,
wherever possible. Simultaneously, <sys/param.h> has been wittled
down to not expose many symbols which are CSRGisms or only used by
_KERNEL code.
<sys/param.h> is still fully supported and usable, but the base is
completely refactored to use the better practice (for cleanliness,
but also as a demonstration of good practice moving forward).
So in the base, only 185 includes of <sys/param.h> exist. This is to
support uses of the following by programs in the base:
1 ALIGNBYTES
1 ALIGNED_POINTER
1 MID_MACHINE (our own infection...)
1 NOFILE_MAX
2 BSD
2 PAGE_SHIFT
2 PZERO
3 MACHINE_ARCH (our own infection...)
3 isclr
4 MACHINE (our own infection...)
4 clrbit
4 powerof2
5 dbtob
7 btodb
8 NODEV
11 ALIGN
11 setbit
12 MAX
12 isset
13 nitems (our own infection...)
14 MIN
22 MAXCOMLEN
23 roundup
28 MAXBSIZE
38 DEV_BSIZE
The inclusion of <sys/param.h> via <netdb.h> and <arpa/nameser.h> has
been terminated, and the ports tree was repaired (simpler than originally
thought. 10 programs?) The most scary impact is that "BSD" will no
longer be defined in some enviroments which picked it up via <netdb.h>
or <arpa/nameser.h>, so we'll have to keep an eye out for such failures.
Finally, this brings us back to MIN() and MAX(), in your original
question. There were quite a few uses of this. To avoid the
namespace poisoning I replaced all uses with local #define's of
MINIMUM() and MAXIMUM(), and will revisit looking for other solutions
later...
