LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Alexey Dobriyan <adobriyan@gmail.com>,
	dsterba@suse.cz, Christoph Hellwig <hch@infradead.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] proc: use #pragma once
Date: Fri, 4 May 2018 03:58:32 +0100	[thread overview]
Message-ID: <20180504025832.GF30522@ZenIV.linux.org.uk> (raw)
In-Reply-To: <94db646a-4fd8-9ce3-2111-b2e4852ad324@rasmusvillemoes.dk>

On Fri, May 04, 2018 at 01:23:12AM +0200, Rasmus Villemoes wrote:
> > Note that sequence of preprocessor tokens does not depend upon the ifdefs;
> > anything under #if 0 *is* tokenized all the same.  So it's not even that
> > "parsing" (tokenizing, actually) has to be repeated.
> 
> Are you sure about that? Maybe formally it has to (if the phases are
> done strictly sequentially), but can't it go into some fast-forward mode
> under #if 0 (or #ifndef $some-defined-macro) where it only looks for
> string and char literals, comments and "control-flow" directives?

What else do you expect preprocessor tokenizer to do?  It must take care
of line continuations, it must recognize and skip whitespace (including
comments) and if it recognizes string and character literals, what else
is left to do?  pp-numbers?  Sure - that'd be
	[.]?[0-9]([0-9a-zA-Z_.]|[epEP][-+])*
Horribly hard to recognize, that...  Identifiers are no harder, obviously
(especially since keywords are _not_ something special at that level)
and punctuators are also easily taken care of.

Preprocessor tokens are nowhere near as much work as C ones.  And you
can't do mapping to C ones before the preprocessing is done - if nothing
else, quoting and token concatenation needs to happen first.

      reply	other threads:[~2018-05-04  2:58 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-23 21:35 Alexey Dobriyan
2018-04-24 13:54 ` Christoph Hellwig
2018-04-25 20:55   ` Alexey Dobriyan
2018-04-26 10:26     ` David Sterba
2018-04-26 10:33       ` Christoph Hellwig
2018-04-26 19:25         ` Alexey Dobriyan
2018-04-26 19:24       ` Alexey Dobriyan
2018-05-01 22:13         ` Andrew Morton
2018-05-03 22:14           ` Rasmus Villemoes
2018-05-03 22:42             ` Al Viro
2018-05-03 23:23               ` Rasmus Villemoes
2018-05-04  2:58                 ` Al Viro [this message]

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=20180504025832.GF30522@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=adobriyan@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=dsterba@suse.cz \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --subject='Re: [PATCH] proc: use #pragma once' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).