From: Jon Loeliger <jdl@jdl•com>
To: David Gibson <david@gibson•dropbear.id.au>
Cc: linuxppc-dev@ozlabs•org
Subject: Re: dtc: Clean up lexing of include files
Date: Mon, 14 Jul 2008 13:55:13 -0500 [thread overview]
Message-ID: <E1KITCb-0006rX-Pp@jdl.com> (raw)
In-Reply-To: <20080626070857.GA1869@yookeroo.seuss>
> Currently we scan the /include/ directive as two tokens, the
> "/include/" keyword itself, then the string giving the file name to
> include. We use a special scanner state to keep the two linked
> together, and use the scanner state stack to keep track of the
> original state while we're parsing the two /include/ tokens.
>
> This does mean that we need to enable the 'stack' option in flex,
> which results in a not-easily-suppressed warning from the flex
> boilerplate code. This is mildly irritating.
>
> However, this two-token scanning of the /include/ directive also has
> some extremely strange edge cases, because there are a variety of
> tokens recognized in all scanner states, including INCLUDE. For
> example the following strange dts file:
>
> /include/ /dts-v1/;
> / {
> /* ... */
> };
>
> Will be processed successfully with the /include/ being effectively
> ignored: the '/dts-v1/' and ';' are recognized even in INCLUDE state,
> then the ';' transitions us to PROPNODENAME state, throwing away
> INCLUDE, and the previous state is never popped off the stack. Or
> for another example this construct:
> foo /include/ = "somefile.dts"
> will be parsed as though it were:
> foo = /include/ "somefile.dts"
> Again, the '=' is scanned without leaving INCLUDE state, then the next
> string triggers the include logic.
>
> And finally, we use a different regexp for the string with the
> included filename than the normal string regexpt, which is also
> potentially weird.
>
> This patch, therefore, cleans up the lexical handling of the /include/
> directive. Instead of the INCLUDE state, we instead scan the whole
> include directive, both keyword and filename as a single token. This
> does mean a bit more complexity in extracting the filename out of
> yytext, but I think it's worth it to avoid the strageness described
> above. It also means it's no longer possible to put a comment between
> the /include/ and the filename, but I'm really not very worried about
> breaking files using such a strange construct.
Applied.
jdl
prev parent reply other threads:[~2008-07-14 18:55 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-26 7:08 dtc: Clean up lexing of include files David Gibson
2008-07-14 18:55 ` Jon Loeliger [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=E1KITCb-0006rX-Pp@jdl.com \
--to=jdl@jdl$(echo .)com \
--cc=david@gibson$(echo .)dropbear.id.au \
--cc=linuxppc-dev@ozlabs$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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