public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: David Brown <david.brown@hesbynett.no>
To: Hirrolot <hirrolot@gmail.com>, gcc-help@gcc.gnu.org
Subject: Re: Prohibit use of break/continue in a statement
Date: Mon, 31 Jan 2022 17:50:12 +0100	[thread overview]
Message-ID: <07c3e8cb-458e-2ec9-a0fd-0ee3cbeaf8d8@hesbynett.no> (raw)
In-Reply-To: <CA+g-_moF7qTvTZauzko_FDMW=O2ZL+UgdCZqfyD_uztYq=mxCA@mail.gmail.com>

On 31/01/2022 16:54, Hirrolot via Gcc-help wrote:
> I have a macro that expands to a for-loop. It is used as follows:
> 
>     MACRO(...) {
>         // User code
>     }
> 
> The for-loop is used to open a new scope with a new variable; thus,
> `MACRO(...) { ... }` would be a proper C statement. The loop itself is
> executed only once.
> 
> The problem is that if a user uses `break` or `continue` like this:
> 
>     while (i < 10) {
>         MACRO(...) {
>            break;
>             // User code...
>        }
>     }
> 
> Then that `break` will apply to the for-loop generated by `MACRO`, not
> to the outer while-loop. The same holds for `continue`. This is
> unexpected behaviour, and I would like to prohibit the use of the
> `break`/`continue` statements in a user statement placed after
> `MACRO`. Ideally, this should somehow trigger a compilation
> error/warning.
> 
> It should be clarified that `MACRO` is not of a loop itself: it is not
> a for-each macro or something like this; using that for-loop is just
> an implementation detail. I would be also happy with getting rid of
> that for-loop but I have no idea how. If I just generate a variable
> like this:
> 
>     #define MACRO(...) int x; /* Some other stuff */
> 
> Then `MACRO(...) { ... }` will no longer be a single C statement.
> Moreover, two occurrences of `MACRO` calls in a single scope will
> result in a compilation error, which is also quite unfortunate.
> 
> Is it possible to trigger a compilation warning/error for
> `break`/`continue` with GCC?
> 

The only thing I can think of is:

#define break DON'T USE BREAK HERE
#define continue DON'T USE CONTINUE HERE

That should cause a compilation error if "break" or "continue" are used.
 Of course, you need to use the #define and a matching #undef in the
places MACRO is used.  And it's undefined behaviour to use keywords as
macro names, so other bad things might happen.

A far better idea would be to explain what you are trying to achieve
with your MACRO, and show your current definition.  Then people could
perhaps give you useful advice!

David



  reply	other threads:[~2022-01-31 16:50 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-31 15:54 Hirrolot
2022-01-31 16:50 ` David Brown [this message]
     [not found]   ` <CA+g-_moR9HXz3rLH6WEeAEq1DXHhyAS9-8DxwLdvNNXzAUGJCg@mail.gmail.com>
2022-01-31 17:00     ` Fwd: " Hirrolot
2022-01-31 17:11       ` Al K
2022-01-31 18:44         ` Hirrolot
2022-02-01  8:53           ` Al K

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=07c3e8cb-458e-2ec9-a0fd-0ee3cbeaf8d8@hesbynett.no \
    --to=david.brown@hesbynett.no \
    --cc=gcc-help@gcc.gnu.org \
    --cc=hirrolot@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 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 read-only IMAP folder(s) and NNTP newsgroup(s).