Date: Mon, 28 Jun 2004 15:59:40 -0400 (EDT) From: Andrew Gallatin <gallatin@cs.duke.edu> To: Brian Fundakowski Feldman <green@FreeBSD.org> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/vm vm_map.c Message-ID: <16608.30892.745161.730935@grasshopper.cs.duke.edu> In-Reply-To: <20040628193858.GG5635@green.homeunix.org> References: <200406281915.i5SJFeaV060231@repoman.freebsd.org> <20040628152232.A2977@grasshopper.cs.duke.edu> <20040628193858.GG5635@green.homeunix.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Brian Fundakowski Feldman writes:
> On Mon, Jun 28, 2004 at 03:22:33PM -0400, Andrew Gallatin wrote:
> > Andrew Gallatin [gallatin@FreeBSD.org] wrote:
> > > gallatin 2004-06-28 19:15:40 UTC
> > >
> > > FreeBSD src repository
> > >
> > > Modified files:
> > > sys/vm vm_map.c
> > > 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.
> >
> > Why are min() and max() inlines which operate on ints? This seems
> > like a real landmine for 64-bit platforms..
>
> Also, why is GCC not generating the correct warnings? The values passed
> in were definitely a 64-bit type. Thanks for finding and fixing this.
I wish I knew. I'm afraid this may bite us at some other point?
> The inlines seem to exist to work around the effect of using macros
> unknowingly on statements with side effects. These should really be
> MIN(), and there seems to have been an extra tab that crept in. Do
> you think you could change those things?
Sure. Already done. Thanks for the blessing to use MIN().
Drew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?16608.30892.745161.730935>