mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Robert P. J. Day" <rpjday@mindspring.com>
To: Adrian Bunk <bunk@stusta.de>
Cc: LKML <linux-kernel@vger.kernel.org>, Oleg Verych <olecom@flower.upol.cz>
Subject: Re: why test for "__GNUC__"?
Date: Sun, 29 Oct 2006 12:37:36 -0500 (EST)	[thread overview]
Message-ID: <Pine.LNX.4.64.0610291223520.31583@localhost.localdomain> (raw)
In-Reply-To: <20061029171855.GF27968@stusta.de>

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

  reply	other threads:[~2006-10-29 17:41 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-29 11:13 Robert P. J. Day
2006-10-29 11:44 ` Jan Engelhardt
2006-10-29 12:44   ` Robert P. J. Day
2006-10-29 12:05     ` Alexey Dobriyan
2006-10-29 15:48       ` Robert P. J. Day
2006-10-29 16:17         ` Oleg Verych
2006-10-29 17:18           ` Adrian Bunk
2006-10-29 17:37             ` Robert P. J. Day [this message]
2006-10-29 18:23               ` Oleg Verych
2006-10-30  3:38               ` Adrian Bunk
2006-10-30  5:08                 ` Kyle Moffett
2006-10-29 16:59         ` Valdis.Kletnieks

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.64.0610291223520.31583@localhost.localdomain \
    --to=rpjday@mindspring.com \
    --cc=bunk@stusta.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=olecom@flower.upol.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®