[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20110413203608.GA4284@p183>
Date: Wed, 13 Apr 2011 23:36:08 +0300
From: Alexey Dobriyan <adobriyan@...il.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Oleg Nesterov <oleg@...hat.com>, linux-kernel@...r.kernel.org,
behlendorf1@...l.gov
Subject: Re: [PATCH] remove abs64()
On Wed, Apr 13, 2011 at 01:26:29PM -0700, Andrew Morton wrote:
> On Wed, 13 Apr 2011 22:20:31 +0200
> Oleg Nesterov <oleg@...hat.com> wrote:
>
> > > > But, we have some stupid users which do something like abs(u32_value)
> > > > and expecting that abs() should treat this value as "signed".
> > > >
> > >
> > > um, yes, I'd forgotten that one. That's a show-stopper.
> >
> > May be we can demand to fix them?
> >
> > I agree with Alexey, it is a bit ugly to have abs() and abs64(), and abs()
> > itself doesn't look very nice.
> >
> > What if we simply add
> >
> > BUILD_BUG_ON( (typeof(_x)-1) > 0 );
> >
> > into abs()?
> >
> > After that it would be trivial to find the offenders and fix them,
> >
> > - abs(unsigned_int)
> > + abs((int) unsigned_int)
>
> Something like that. But it should be done before we change abs(), to
> avoid nasty breakage in obscure places.
>
> Or we rework the abs() implementation so that the abs(unsigned)
> behavior is unchanged.
>
> There will remain the problem that the abs() return value's signedness
> has changed.
Maybe I can sneak in kabs() ang gradually convert?
Reading abs(3) manpage, it returns int minumum, so semantic change
notice would be nice.
Anyway patch as posted was buggy in the following sense:
_b_t_c_p(char, signed char) == 0
AND
_b_t_c_p(char, unsigned char) == 0
so if char is signed, it doesn't work.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists