cvs commit: src/sys/vm vm_map.c

[David Schultz]

On Wed, Jun 30, 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:
> > > >  > On Mon, 28 Jun 2004, Andrew Gallatin wrote:
> > > >  > >  > > >   Log:
> > > >  > >  > > >   Fix alpha - the use of min() on longs was loosing the high bits and
> > > >  > >  > > >   returning wrong answers, leading to strange values vm2->vm_{s,t,d}size.
> > > >  >
> > > >  > 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!

Erm...the only places where people should be using min() and max()
over MIN() and MAX() is where double expansion is problematic.
It really says something about the limitations of your language
when you're allowed to have type independence or applicative order
argument evaluation, but not both.