All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Whitcroft <apw@canonical.com>
To: Ivo Sieben <meltedpianoman@gmail.com>
Cc: linux-kernel@vger.kernel.org, Joe Perches <joe@perches.com>
Subject: Re: [PATCH] [checkpatch.pl] ctx_statement_block #if/#else/#endif fix
Date: Wed, 11 Jun 2014 10:16:40 +0100	[thread overview]
Message-ID: <20140611091640.GK6819@bark> (raw)
In-Reply-To: <1400164995-8652-1-git-send-email-meltedpianoman@gmail.com>

On Thu, May 15, 2014 at 04:43:15PM +0200, Ivo Sieben wrote:
> When picking up a complete statement block #if/#else/#endif prepocesor
> boundaries are taken into account by pushing current level & type on a stack.
> But on an #else the level was read from stack again (without actually popping it
> from stack) causing the statement block to end too early on the next ';'.
> Fixed this.
> 
> For example the following code:
> 
>  	if (!test()) {
>  #ifdef NEVER
>  		foo();
>  		bar();
>  #else
>  		bar();
>  		foo();
>  #endif
>  	}
> 
> Results in statement block:
> 
>  STATEMENT<+    if (!test()) {
>  +#ifdef NEVER
>  +              foo();
>  +              bar();
>  +#else
>  +              bar();>
>  CONDITION<+    if (!test())>
> 
> While you would expect:
> 
>  STATEMENT<+    if (!test()) {
>  +#ifdef NEVER
>  +              foo();
>  +              bar();
>  +#else
>  +              bar();
>  +              foo();
>  +#endif
>  +       }>
>  CONDITION<+     if (!test())>
> 
> Signed-off-by: Ivo Sieben <meltedpianoman@gmail.com>
> ---
> 
> Request for comments:
> I think I fixed a problem here that I encountered while I was working on another
> changeset in which I check the statement block after a condition.
> Somehow the statement block did not contain everything I expected.
> 
>  scripts/checkpatch.pl |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 34eb216..e7bca89 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -878,7 +878,7 @@ sub ctx_statement_block {
>  		if ($remainder =~ /^#\s*(?:ifndef|ifdef|if)\s/) {
>  			push(@stack, [ $type, $level ]);
>  		} elsif ($remainder =~ /^#\s*(?:else|elif)\b/) {
> -			($type, $level) = @{$stack[$#stack - 1]};
> +			# no changes to stack: type & level remain the same
>  		} elsif ($remainder =~ /^#\s*endif\b/) {
>  			($type, $level) = @{pop(@stack)};
>  		}
> @@ -1050,7 +1050,7 @@ sub ctx_block_get {
>  		if ($lines[$line] =~ /^.\s*#\s*(?:ifndef|ifdef|if)\s/) {
>  			push(@stack, $level);
>  		} elsif ($lines[$line] =~ /^.\s*#\s*(?:else|elif)\b/) {
> -			$level = $stack[$#stack - 1];
> +			# no changes to stack: type & level remain the same
>  		} elsif ($lines[$line] =~ /^.\s*#\s*endif\b/) {
>  			$level = pop(@stack);
>  		}
> -- 
> 1.7.9.5

It doesn't seem right to remove the restore of the state.  If you
consider the effect of an #if/#else/#endif combination the state of the
statement parser should be reset to the state at #if at the #else as the
code there is an alternative for the code in the other branch(s) of the
preprocessor, either is a continuation of the statement in progress when
reached.  This contrived example should make it clear we need to
restore:

	c = (d +
#if A
	a)
#else
	b)
#endif


That said it appears to be doing something wrong in your example.

/me will have a poke and get back to you.

-apw


  parent reply	other threads:[~2014-06-11  9:16 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-15 14:43 [PATCH] [checkpatch.pl] ctx_statement_block #if/#else/#endif fix Ivo Sieben
2014-06-10  6:19 ` Ivo Sieben
2014-06-10 16:24   ` Joe Perches
2014-06-11  9:16 ` Andy Whitcroft [this message]
2014-06-11  9:57   ` Andy Whitcroft
2014-06-11  9:59     ` Andy Whitcroft

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=20140611091640.GK6819@bark \
    --to=apw@canonical.com \
    --cc=joe@perches.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=meltedpianoman@gmail.com \
    /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.