cvs commit: src/sys/vm vm_map.c

[Bruce Evans]

On Wed, 30 Jun 2004, Brian Fundakowski Feldman wrote:

> On Tue, Jun 29, 2004 at 08:02:48PM -0700, David Schultz wrote:
> > On Wed, Jun 30, 2004, Bruce Evans wrote:
> > > On Tue, 29 Jun 2004, Andrew Gallatin wrote:
> > >
> > > > Bruce Evans writes:
> > > >  > MIN() and MAX() should not be used in the kernel.  4.4BSD removed them in
> > > >  > the kernel, but FreeBSD broke this in rev.1.141 of sys/param.h.  They
> > > >  > remain removed in RELENG_4.
> > > >
> > > > OK.  Then what's the correct fix? ulmin()?
> > >
> > > Fixing min() to handle all unsigned types is probably best.
> >
> > Hmm...but this means either
> >
> > a) slightly pessimizing 32-bit ports with a function on uintmax_t's,
> >
> > b) using a macro and introducing double-expansion problems, or
> >
> > c) using GCC extensions
> >
> > Option (c) seems best from a technical standpoint, except that
> > we'd be making it harder than it already is to compile the kernel
> > with compilers other than gcc and icc.  (Do others have the
> > statement expr extension?)
>
> No, the correct fix is using MIN() or MAX() that are well-documented
> to provide the exact side-effects C programmers know to expect.  They
> automatically return the correct type, too, with no coercion!

No.  MIN() and MAX() are not documented.  The don't even exist in the
kernel in FreeBSD-[2-4].

They only return the correct type in some cases.  E.g., the correct
type and value for MIN((foo_t)1, (bar_t)-1) is unclear, since foo_t
might be unsigned and bar_t might be signed, and/or have different
sizes:

Case foo_t is unsigned char and bar_t is signed char, and chars are smaller
than ints:  the result is MIN(1, -1) = -1 and has type int.

Case foo_t is unsigned int and bar_t is signed int: the result is
min(1u, -1) = UINT_MAX and has type unsigned int.

So programmers must still be aware of the types of the operands if the
operand types are significantly different.

Bruce