All of lore.kernel.org
 help / color / mirror / Atom feed
From: daw@cs.berkeley.edu (David Wagner)
To: linux-kernel@vger.kernel.org
Subject: Re: [patch 1/1] consolidate TRUE and FALSE
Date: Thu, 16 Mar 2006 23:53:36 +0000 (UTC)	[thread overview]
Message-ID: <dvctq0$c0o$1@taverner.CS.Berkeley.EDU> (raw)
In-Reply-To: 20060316082951.58592fdc.rdunlap@xenotime.net

Randy.Dunlap wrote:
>nah, the only place that using symbolic names for true and false
>is a problem is when someone #defines or enums them bassackwards.

Here's another danger associated with #define TRUE:
    int x = ...;
    if (x == TRUE)
        do_something();
A surprise happens if x is initialized to something other than 0 or 1.
Looks like there maybe as many as a hundred instances of the above
pattern in the kernel.  Most of them seem safe, but I don't know whether
they all are, and there are too many for me to check them all.

For instance, take a look at net/core/ethtool.c:ethtool_set_rx_csum()
and drivers/net/ixgb/ixgb_ethtool.c:ixgb_set_rx_csum() and
drivers/net/ixgb/ixgb_main.c:ixgb_configure_rx() for how it handles
adapter->rx_csum to see one example that strikes me as dubious.

  parent reply	other threads:[~2006-03-16 23:53 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-16 10:01 [patch 1/1] consolidate TRUE and FALSE akpm
2006-03-16 10:28 ` Anton Altaparmakov
2006-03-16 10:42   ` Andrew Morton
2006-03-16 19:55     ` Nicholas Miell
2006-03-16 19:55     ` Jan Engelhardt
2006-03-16 10:36 ` Arjan van de Ven
2006-03-16 16:01 ` Christoph Hellwig
2006-03-16 16:29   ` Randy.Dunlap
2006-03-16 16:30     ` Christoph Hellwig
2006-03-16 16:36       ` Randy.Dunlap
2006-03-16 16:36         ` Christoph Hellwig
2006-03-16 16:42           ` Anton Altaparmakov
2006-03-16 16:50             ` Al Viro
     [not found]               ` <2c0942db0603160905v26011d8dx1e64967b2eb4deac@mail.gmail.com>
2006-03-16 17:11                 ` Al Viro
2006-03-16 18:50               ` Anton Altaparmakov
2006-03-16 18:53                 ` Anton Altaparmakov
2006-03-16 19:59             ` Jan Engelhardt
2006-03-16 22:35               ` Anton Altaparmakov
2006-03-16 16:42           ` Randy.Dunlap
2006-03-16 16:39       ` Anton Altaparmakov
2006-03-16 17:41       ` Sam Ravnborg
2006-03-16 18:00         ` Al Viro
2006-03-16 18:12           ` Randy.Dunlap
2006-03-16 18:49             ` Al Viro
2006-03-16 18:58               ` Randy.Dunlap
2006-03-16 18:52           ` Sam Ravnborg
2006-03-16 21:17     ` Valdis.Kletnieks
2006-03-16 21:28       ` Joshua Hudson
2006-03-16 23:53     ` David Wagner [this message]
2006-03-16 17:09   ` Xavier Bestel
2006-03-16 16:49 ` Al Viro
2006-03-16 21:26   ` Andrew Morton
2006-03-17 22:43     ` Xavier Bestel
2006-03-17 22:56       ` Andrew Morton
2006-03-18 21:57       ` Jan Engelhardt
2006-03-19 11:41         ` Xavier Bestel
2006-03-16 17:07 ` Greg KH
2006-03-16 17:13   ` Greg KH
2006-03-20 14:46 ` Richard Knutsson

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='dvctq0$c0o$1@taverner.CS.Berkeley.EDU' \
    --to=daw@cs.berkeley.edu \
    --cc=daw-usenet@cs.berkeley.edu \
    --cc=linux-kernel@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.