All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Sparse Mailing-list <linux-sparse@vger.kernel.org>
Subject: Re: [PATCH 15/17] scope: give a scope for labels & gotos
Date: Fri, 15 May 2020 00:22:39 +0200	[thread overview]
Message-ID: <20200514222227.n3hvic3lndz5qcjv@ltop.local> (raw)
In-Reply-To: <CAHk-=whoCQ9hiNsNS_PKJGt+dxhXng8+YLJ-CzGG0eESfv0f0g@mail.gmail.com>

On Tue, Apr 14, 2020 at 05:59:18PM -0700, Linus Torvalds wrote:
> On Tue, Apr 14, 2020 at 4:09 PM Luc Van Oostenryck
> <luc.vanoostenryck@gmail.com> wrote:
> >
> > +                       if (s->scope != s->declared_scope) {
> >
> > This comparison can never succeed for labels declared with __label__
> > because s->scope is a block scope and s->declared_scope a label one.
> 
> Hold on.. I'm sure I tested it.
> 
> Oh.
> 
> What I tested wasn't what I sent you, and I'd fixed things due to the
> testing but not updated the patch file.
> 
> Oops.
> 
> The test is supposed to be
> 
>                         if (s->declared_scope != label_scope) {
> 
> which is the whole point of that 'declared_scope'.
> 
> So the concept of the patch is that the 'declared_scope' (and
> 'label_scope') are the same kind of scope (and comparable): it is the
> applicability of the label itself (either the whole function or some
> sub-expression statement).
> 
> And the the visibility of the -symbol- ends up being different, and is
> the s->scope thing.
> 
> But while my testing wasn't quite as limited as my wrong-version patch
> implied, it _was_ limited. So it might miss some other case.

Sorry for the late reply.

Yes, it's working OK wth this change but there are several issues that
make me think that this approach is not ideal:

1) these 2 functions would give very different error message:
	void foo(void)
	{
		goto l;
		({ l: 0; });
	}

	void bar(void)
	{
		({ l: 0; });
		goto l;
	}

  The first one gives the 'warning: jumping inside statement expression'
  while the second one can only give 'warning: goto with undeclared label'
  because indeed the 'l' label inside the statement isn't visible anymore.
  This second warning is of coure less informative than the first one
  but what I really find abnormal is that the warning would be different
  depending on the fact that the goto comes before or after the label
  definition. This seems incorrect to me, confusing and is different
  from GCC (clang doesn't seems to mind).

2) in the following case, no warning can be given:
	void foo(void)
	{
	l:
		({
		l:
			goto l;
			0;
		});
		goto l;
	}
  
   In this case both label definition are in a different scope and each goto
   sees its own label. This is different than GCC which would complain
   about 'l' being redeclared.

   There was also another issue related to the fact that GCC put all
   labels in a single namespace bit I forgot the details.


These two problems are linked to the fact of using the local namespace
for labels while GCC use a single one for all of them.
But well, then again I can't say I'm fully happy with my solution
using the label scope not for the labels but for their definition
and uses (gotos & label expressions) and then comparing these with
the helper is_in_scope().

I dunno. I've fixed a number of details, I'll repost everything soon.

-- Luc

  reply	other threads:[~2020-05-14 22:22 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-13 16:15 [PATCH 00/17] detect invalid branches at evaluation time Luc Van Oostenryck
2020-04-13 16:15 ` [PATCH 01/17] bad-goto: add testcase for 'jump inside discarded expression statement' Luc Van Oostenryck
2020-04-13 16:15 ` [PATCH 02/17] bad-goto: add testcases for linearization of invalid labels Luc Van Oostenryck
2020-04-13 16:15 ` [PATCH 03/17] bad-goto: add more testcases Luc Van Oostenryck
2020-04-13 16:15 ` [PATCH 04/17] bad-goto: do not linearize if the IR will be invalid Luc Van Oostenryck
2020-04-13 16:15 ` [PATCH 05/17] bad-goto: reorg test in evaluate_goto_statement() Luc Van Oostenryck
2020-04-13 16:15 ` [PATCH 06/17] bad-goto: simplify testing of undeclared labels Luc Van Oostenryck
2020-04-13 16:15 ` [PATCH 07/17] bad-goto: do not linearize function with " Luc Van Oostenryck
2020-04-13 16:15 ` [PATCH 08/17] bad-goto: catch labels with reserved names Luc Van Oostenryck
2020-04-13 16:15 ` [PATCH 09/17] scope: no memset() needed after __alloc_scope() Luc Van Oostenryck
2020-04-13 16:15 ` [PATCH 10/17] scope: move scope opening/ending inside compound_statement() Luc Van Oostenryck
2020-04-13 16:15 ` [PATCH 11/17] scope: make function scope the same as the body block scope Luc Van Oostenryck
2020-04-13 16:16 ` [PATCH 12/17] scope: s/{start,end}_symbol_scope/{start,end}_block_scope/ Luc Van Oostenryck
2020-04-13 16:16 ` [PATCH 13/17] scope: let labels have their own scope Luc Van Oostenryck
2020-04-13 17:30   ` Linus Torvalds
2020-04-13 16:16 ` [PATCH 14/17] scope: add is_in_scope() Luc Van Oostenryck
2020-04-13 16:16 ` [PATCH 15/17] scope: give a scope for labels & gotos Luc Van Oostenryck
2020-04-13 17:52   ` Linus Torvalds
2020-04-13 18:54     ` Luc Van Oostenryck
2020-04-13 19:32       ` Linus Torvalds
2020-04-13 20:00         ` Luc Van Oostenryck
2020-04-13 22:40         ` Linus Torvalds
2020-04-13 23:39           ` Luc Van Oostenryck
2020-04-14  7:49             ` Luc Van Oostenryck
2020-04-14 18:19               ` Linus Torvalds
2020-04-14 23:09                 ` Luc Van Oostenryck
2020-04-15  0:59                   ` Linus Torvalds
2020-05-14 22:22                     ` Luc Van Oostenryck [this message]
2020-04-13 16:16 ` [PATCH 16/17] bad-goto: catch gotos inside expression statements Luc Van Oostenryck
2020-04-13 16:16 ` [PATCH 17/17] bad-goto: cleanup evaluate_goto() Luc Van Oostenryck

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=20200514222227.n3hvic3lndz5qcjv@ltop.local \
    --to=luc.vanoostenryck@gmail.com \
    --cc=linux-sparse@vger.kernel.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.