All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josh Triplett <josh@freedesktop.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Pavel Roskin <proski@gnu.org>, linux-sparse@vger.kernel.org
Subject: Re: Feature request - allow boolean operations of undefined cpp symbols
Date: Fri, 20 Apr 2007 03:02:10 -0700	[thread overview]
Message-ID: <46288FA2.4040700@freedesktop.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0702021021570.15057@woody.linux-foundation.org>

[-- Attachment #1: Type: text/plain, Size: 2629 bytes --]

Linus Torvalds wrote:
> On Fri, 2 Feb 2007, Pavel Roskin wrote:
>> I think sparse should distinguish between safe and unsafe preprocessor
>> operations on undefined symbols.
[...]
>> For instance, "#if SYMBOL" has a very specific meaning
> 
> No.
> 
> 	#if SYMBOL
> 
> has a very specific *problem* - it very possibly is a typo.
> 
> So this is a warning I absolutely *want* for the kernel. If some other 
> projects don't want it, fine, but it should be on by default as a warnign 
> for potentially dangerous use of preprocessor symbols.

I looked this behavior up in the C99 standard, and found the following text in
section 6.10.1:
> Prior to evaluation, macro invocations in the list of preprocessing tokens
> that will become the controlling constant expression are replaced (except
> for those macro names modified by the defined unary operator), just as in
> normal text. If the token defined is generated as a result of this
> replacement process or use of the defined unary operator does not match one
> of the two specified forms prior to macro replacement, the behavior is
> undefined. After all replacements due to macro expansion and the defined
> unary operator have been performed, all remaining identifiers are replaced
> with the pp-number 0, and then each preprocessing token is converted into a
> token. The resulting tokens compose the controlling constant expression
> which is evaluated according to the rules of 6.6.

This states that we must substitute 0 for any undefined preprocessor symbol
in a #if or #elif condition, no matter what kind of expression they show up
in.  I confirmed this behavior via both GCC and Sparse; in an #if, "-1 <
SOMESYMBOL" evaluates true, and "1 < SOMESYMBOL" evaluates false.  Sparse
follows this spec precisely with respect to actual preprocessor behavior; it
simply has the ability to warn.

GCC has an equivalent option, also named -Wundef, that also generates a
warning.  Like Sparse, GCC does not issue this warning by default; GCC does
not include it in -Wall either.  For both Sparse and GCC, you have to turn it
on the warning for it to occur.

All of this makes me disinclined to turn -Wundef on by default.  However, I
also see no reason to change the current behavior of -Wundef.  GCC will also
give you a warning if you give -Wundef.  Just don't pass -Wundef if you have
valid conditionals in your project that generate warnings about undefined
preprocessor symbols.

However, Pavel, if you feel you could make part of -Wundef suitable to join
the default set of warnings, feel free.

- Josh Triplett


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

  parent reply	other threads:[~2007-04-20 10:02 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-02 17:37 Feature request - allow boolean operations of undefined cpp symbols Pavel Roskin
2007-02-02 18:25 ` Linus Torvalds
2007-02-02 21:56   ` Christopher Li
2007-02-02 22:30     ` Pavel Roskin
2007-02-02 22:10       ` Christopher Li
2007-02-02 22:58         ` Pavel Roskin
2007-02-02 22:45     ` Linus Torvalds
2007-04-20 10:02   ` Josh Triplett [this message]
2007-04-20 22:42     ` Pavel Roskin

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=46288FA2.4040700@freedesktop.org \
    --to=josh@freedesktop.org \
    --cc=linux-sparse@vger.kernel.org \
    --cc=proski@gnu.org \
    --cc=torvalds@linux-foundation.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.