WANG Cong wrote: > On Mon, Nov 19, 2007 at 09:10:44PM -0800, H. Peter Anvin wrote: >> WANG Cong wrote: >>> On Tue, Nov 20, 2007 at 10:13:42AM +0800, zhengyi wrote: >>>> Is there any relevance to the kernel ? >>>> >>>> I found the folowing code here: >>>> http://linux.solidot.org/article.pl?sid=07/11/19/0512218&from=rss >>>> >>>> ------------------------------------------------------------------- >>>> int main( void ) >>>> { >>>> int i=2; >>>> if( -10*abs (i-1) == 10*abs(i-1) ) >>>> printf ("OMG,-10==10 in linux!\n"); >>>> else >>>> printf ("nothing special here\n") ; >>>> >>>> return 0 ; >>>> } >>> I think no. It is considered a bug in abs(), kernel, of course, >>> doesn't use glibc's abs(). >>> >> Wrong. >> >> abs() is internal to gcc, and the above is optimized out at compile >> time, so any user of abs() as a function at all is vulnerable. > > This is an urgent bug, I think. > > And you mean abs() is not in glibc, then where is it? Built in gcc? > And what's more, why not put it in glibc? >
Gcc optimises abs() to use gcc builtin-in abs(). So if we use -fno-builin, we'll get the correct result. That is to say the bug has nothing to do with glibc. And this bug has been fixed just several days ago. http://www.nabble.com/-PATCH--Fix-PR34130,-extract_muldiv-broken-t4826688.html > >> However, the Linux kernel defines abs() as a macro: >> >> #define abs(x) ({ \ >> int __x = (x); \ >> (__x < 0) ? -__x : __x; \ >> }) >> >> ... which means gcc never sees it. So the kernel isn't affected, >> because it doesn't use *gcc's* abs(). > > Thanks for clarifying this! > > Regards. > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/