Re: why test for "__GNUC__"?

["Robert P. J. Day" <rpjday@mindspring.com>]

On Sun, 29 Oct 2006, Adrian Bunk wrote:

> On Sun, Oct 29, 2006 at 04:17:51PM +0000, Oleg Verych wrote:
> >...
> > On 2006-10-29, Robert P. J. Day wrote:
> >>...
> > And if you can, please, help with development or bugs, not this.
>
> Cleanup of the kernel source is also a valuable task (and as a side
> effect it even sometimes finds bugs).

on that note, i realize that most of my postings are addressing
nitpicky/aesthetic issues that don't actually *hurt* anything, but for
someone who's clawing his way through the kernel code for the first
time, a lot of it is unnecessarily confusing.

for better or worse, i generally assume that whatever i'm looking at
is there for a *reason* and i might spend some time puzzling over a
bit of code until it finally dawns on me that it's just historical
cruft that has no value.  it's not a bug, it just doesn't *do*
anything anymore.

in my case, it's sometimes easier to spot things like this since i'm
following along in some book, like r. love's "linux kernel
development."  so when he writes that the linux kernel is wedded to
gcc, and yet i see tests for "__GNUC__" throughout the code, my little
antenna stalks perk up a bit.

having someone point out that ICC is also an option clarifies that
briefly ... until i notice that ICC *also* defines __GNUC__ equal to
4, so i'm back to being confused.  (as an aside, i downloaded the most
recent ICC earlier today and did a test compile of the latest git
pull.  man, the stuff under scripts/ needs to be cleaned something
fierce.  :-)

then there's the apparently historical stuff related to "signed"
versus "__signed" versus "__signed__".  sure, it all works, but it's
needlessly complicated and verbose and might also lead someone astray
trying to figure out what the rationale is.  (and don't even get me
started on semaphores. :-)

in any event, i'm most emphatically *not* (yet) at the level where i'm
going to be able to contribute bleeding-edge code.  but i'm certainly
capable of poring over the *existing* code and pointing out the places
that might lead someone to mutter, "what the hell...?"

maybe there's a better forum for me to make these observations.  i'm
open to suggestions.  i've made a list of these observations and i'd
be happy to send them to the right person.

rday
-
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/