lkml.org 
[lkml]   [2001]   [Aug]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [IDEA+RFC] Possible solution for min()/max() war
Date
"A month of sundays ago David Woodhouse wrote:"
>
> ptb@it.uc3m.es said:
> > You got me curious enough to try it. It compiles and links fine with
> > -O1 and higher under
>
> > gcc version 2.95.2 20000220 (Debian GNU/Linux)
> > gcc version 2.8.1
> > gcc version 2.7.2.3
>
> Oh well, then it _must_ be safe then - gcc has never changed unspecified
> behaviour on us before, has it?

Well, I understand what you mean, but if the linux kernel wants it
and the C spec doesn't forbid it, then it'll either stay that way
or an "official" way will be found of evoking the desired behaviour.

The kernel already relies on -O1 expanding outb().

> The gcc engineer who took one look at the __buggy_udelay cruft, raised his
> eyebrows, swore and wandered off muttering must just have been having a bad
> day or something.

Actually, I was a bit more worried that

const unsigned int i = 1;
if (i < 0)
foo();
would generate warnings about the comparison always failing. But it
doesn't, at least not with -Wall. It does generate a warning about
implicitly declaring the function foo()! So I guess one has to add a
decl for it just above the call. But it doesn't emit code for the call
itself, so the link is fine.

OTOH I now can't get #__LINE__ to expand as I want it where I want it.

Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:01    [W:0.687 / U:0.212 seconds]
©2003-2011 Jasper Spaans. Advertise on this site