Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #141995 > unrolled thread

[ On topic, amazingtly ]: labels and declarations

Back to article view | Back to comp.lang.c

Contents

  [ On topic, amazingtly ]: labels and declarations gazelle@shell.xmission.com (Kenny McCormack) - 2019-03-17 14:45 +0000
    Re: [ On topic, amazingtly ]: labels and declarations nobody@example.org (Scott) - 2019-03-17 17:25 +0000
      Re: [ On topic, amazingtly ]: labels and declarations fir is a sexy shemale <cdalten@gmail.com> - 2019-03-17 10:59 -0700
    Re: [ On topic, amazingtly ]: labels and declarations Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2019-03-17 14:16 -0400
      Re: [ On topic, amazingtly ]: labels and declarations Richard Damon <Richard@Damon-Family.org> - 2019-03-17 18:43 -0400
        Re: [ On topic, amazingtly ]: labels and declarations Bart <bc@freeuk.com> - 2019-03-17 22:55 +0000
          Re: [ On topic, amazingtly ]: labels and declarations Bart <bc@freeuk.com> - 2019-03-18 01:37 +0000
          Re: [ On topic, amazingtly ]: labels and declarations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-03-17 19:46 -0700
            Re: [ On topic, amazingtly ]: labels and declarations David Brown <david.brown@hesbynett.no> - 2019-03-18 08:41 +0100
              Re: [ On topic, amazingtly ]: labels and declarations Bart <bc@freeuk.com> - 2019-03-18 11:20 +0000
                Re: [ On topic, amazingtly ]: labels and declarations "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-18 04:39 -0700
                  Re: [ On topic, amazingtly ]: labels and declarations Bart <bc@freeuk.com> - 2019-03-18 12:08 +0000
                    Re: [ On topic, amazingtly ]: labels and declarations "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-18 05:26 -0700
                      labels and declarations and debugger breakpoints "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-18 05:40 -0700
                      Re: [ On topic, amazingtly ]: labels and declarations Bart <bc@freeuk.com> - 2019-03-18 17:25 +0000
                        Re: [ On topic, amazingtly ]: labels and declarations gazelle@shell.xmission.com (Kenny McCormack) - 2019-03-18 19:11 +0000
                          Re: [ On topic, amazingtly ]: labels and declarations Bart <bc@freeuk.com> - 2019-03-19 01:36 +0000
                        Re: [ On topic, amazingtly ]: labels and declarations "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-18 12:31 -0700
                          Re: [ On topic, amazingtly ]: labels and declarations Bart <bc@freeuk.com> - 2019-03-18 19:57 +0000
                            Re: [ On topic, amazingtly ]: labels and declarations "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-18 13:09 -0700
                              Re: [ On topic, amazingtly ]: labels and declarations Bart <bc@freeuk.com> - 2019-03-18 21:09 +0000
                                Re: [ On topic, amazingtly ]: labels and declarations "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-18 16:03 -0700
                                  Re: [ On topic, amazingtly ]: labels and declarations Bart <bc@freeuk.com> - 2019-03-18 23:49 +0000
                                    Re: [ On topic, amazingtly ]: labels and declarations fir is a sexy shemale <cdalten@gmail.com> - 2019-03-18 16:53 -0700
                                    Re: [ On topic, amazingtly ]: labels and declarations "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-18 18:03 -0700
                Re: [ On topic, amazingtly ]: labels and declarations David Brown <david.brown@hesbynett.no> - 2019-03-18 13:16 +0100
                  Re: [ On topic, amazingtly ]: labels and declarations Bart <bc@freeuk.com> - 2019-03-18 12:30 +0000
                    Re: [ On topic, amazingtly ]: labels and declarations David Brown <david.brown@hesbynett.no> - 2019-03-18 13:41 +0100
                      Re: [ On topic, amazingtly ]: labels and declarations fir <profesor.fir@gmail.com> - 2019-03-18 06:54 -0700
                        Re: [ On topic, amazingtly ]: labels and declarations fir <profesor.fir@gmail.com> - 2019-03-18 07:05 -0700
                          Re: [ On topic, amazingtly ]: labels and declarations fir <profesor.fir@gmail.com> - 2019-03-18 09:07 -0700
              Re: [ On topic, amazingtly ]: labels and declarations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-03-18 06:46 -0700
                Re: [ On topic, amazingtly ]: labels and declarations "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-18 07:25 -0700
          Re: [ On topic, amazingtly ]: labels and declarations Manfred <noname@add.invalid> - 2019-03-21 17:48 +0100
            Re: [ On topic, amazingtly ]: labels and declarations "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-21 10:04 -0700
              Re: [ On topic, amazingtly ]: labels and declarations fir is a sexy shemale <cdalten@gmail.com> - 2019-03-21 10:34 -0700
              Re: [ On topic, amazingtly ]: labels and declarations Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-03-21 20:19 +0000
                Re: [ On topic, amazingtly ]: labels and declarations "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-21 14:29 -0700
                  Re: [ On topic, amazingtly ]: labels and declarations Chad <cdalten@gmail.com> - 2019-03-22 10:15 -0700
                    Re: [ On topic, amazingtly ]: labels and declarations "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-22 13:58 -0700
                      Re: [ On topic, amazingtly ]: labels and declarations Chad <cdalten@gmail.com> - 2019-03-22 15:10 -0700
                        Re: [ On topic, amazingtly ]: labels and declarations "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-22 15:31 -0700
                Re: [ On topic, amazingtly ]: labels and declarations David Brown <david.brown@hesbynett.no> - 2019-03-22 09:22 +0100
                  Re: [ On topic, amazingtly ]: labels and declarations Chad <cdalten@gmail.com> - 2019-03-22 09:28 -0700
              Re: [ On topic, amazingtly ]: labels and declarations Manfred <invalid@add.invalid> - 2019-03-22 18:15 +0100
                Re: [ On topic, amazingtly ]: labels and declarations "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-22 10:51 -0700
                Re: [ On topic, amazingtly ]: labels and declarations Keith Thompson <kst-u@mib.org> - 2019-03-22 11:31 -0700
                  Re: [ On topic, amazingtly ]: labels and declarations Manfred <noname@add.invalid> - 2019-03-23 17:43 +0100
                    Re: [ On topic, amazingtly ]: labels and declarations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-03-23 13:36 -0700
                      Re: [ On topic, amazingtly ]: labels and declarations Richard Damon <Richard@Damon-Family.org> - 2019-03-23 17:37 -0400
                        Re: [ On topic, amazingtly ]: labels and declarations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-03-25 09:18 -0700
                Re: [ On topic, amazingtly ]: labels and declarations James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-03-22 12:59 -0700
                  Re: [ On topic, amazingtly ]: labels and declarations "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-22 14:03 -0700
                    Re: [ On topic, amazingtly ]: labels and declarations David Brown <david.brown@hesbynett.no> - 2019-03-23 12:44 +0100
                      Re: [ On topic, amazingtly ]: labels and declarations Robert Wessel <robertwessel2@yahoo.com> - 2019-03-24 10:10 -0500
                  Re: [ On topic, amazingtly ]: labels and declarations Manfred <noname@add.invalid> - 2019-03-23 17:48 +0100
                    Re: [ On topic, amazingtly ]: labels and declarations James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-03-25 11:32 -0700
            Re: [ On topic, amazingtly ]: labels and declarations Robert Wessel <robertwessel2@yahoo.com> - 2019-03-21 22:22 -0500
              Re: [ On topic, amazingtly ]: labels and declarations Manfred <noname@add.invalid> - 2019-03-22 17:45 +0100
                Re: [ On topic, amazingtly ]: labels and declarations Keith Thompson <kst-u@mib.org> - 2019-03-22 11:13 -0700
                  Re: [ On topic, amazingtly ]: labels and declarations Manfred <noname@add.invalid> - 2019-03-23 18:20 +0100
                    Re: [ On topic, amazingtly ]: labels and declarations Keith Thompson <kst-u@mib.org> - 2019-03-23 11:57 -0700
                      Re: [ On topic, amazingtly ]: labels and declarations James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-03-25 10:58 -0700
                        Re: [ On topic, amazingtly ]: labels and declarations Keith Thompson <kst-u@mib.org> - 2019-03-25 13:17 -0700
        Re: [ On topic, amazingtly ]: labels and declarations Keith Thompson <kst-u@mib.org> - 2019-03-17 16:16 -0700
          Re: [ On topic, amazingtly ]: labels and declarations Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2019-03-17 19:29 -0400
            Re: [ On topic, amazingtly ]: labels and declarations Keith Thompson <kst-u@mib.org> - 2019-03-17 16:49 -0700
              Re: [ On topic, amazingtly ]: labels and declarations Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2019-03-17 19:51 -0400
              Re: [ On topic, amazingtly ]: labels and declarations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-03-17 17:41 -0700
                Re: [ On topic, amazingtly ]: labels and declarations Richard Damon <Richard@Damon-Family.org> - 2019-03-17 22:53 -0400
                  Re: [ On topic, amazingtly ]: labels and declarations Keith Thompson <kst-u@mib.org> - 2019-03-17 21:08 -0700
                    Re: [ On topic, amazingtly ]: labels and declarations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-03-17 21:40 -0700
                      Re: [ On topic, amazingtly ]: labels and declarations gazelle@shell.xmission.com (Kenny McCormack) - 2019-03-18 05:03 +0000
                        Re: [ On topic, amazingtly ]: labels and declarations "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-18 02:30 -0700
                        Re: [ On topic, amazingtly ]: labels and declarations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-03-18 06:32 -0700
                          Re: [ On topic, amazingtly ]: labels and declarations gazelle@shell.xmission.com (Kenny McCormack) - 2019-03-18 16:06 +0000
                  Re: [ On topic, amazingtly ]: labels and declarations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-03-17 22:19 -0700
          Re: [ On topic, amazingtly ]: labels and declarations Richard Damon <Richard@Damon-Family.org> - 2019-03-17 20:07 -0400
    Re: [ On topic, amazingtly ]: labels and declarations luser droog <luser.droog@gmail.com> - 2019-03-17 12:37 -0700
    Re: [ On topic, amazingtly ]: labels and declarations "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2019-03-18 11:00 +0800
      Re: [ On topic, amazingtly ]: labels and declarations "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2019-03-18 22:43 +0800
        Re: [ On topic, amazingtly ]: labels and declarations "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-18 08:00 -0700
          Re: [ On topic, amazingtly ]: labels and declarations "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2019-03-19 13:11 +0800
            Telling Fred where to go... (Was: [ On topic, amazingtly ]: labels and declarations) gazelle@shell.xmission.com (Kenny McCormack) - 2019-03-19 05:27 +0000
              Re: Telling Fred where to go... (Was: [ On topic, amazingtly ]: labels and declarations) "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2019-03-19 14:40 +0800
              Re: Telling Fred where to go... (Was: [ On topic, amazingtly ]: labels and declarations) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-19 04:39 -0700
                Re: Telling Fred where to go... (Was: [ On topic, amazingtly ]: labels and declarations) "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2019-03-19 19:44 +0800
                  Re: Telling Fred where to go... (Was: [ On topic, amazingtly ]: labels and declarations) fir is a sexy shemale <cdalten@gmail.com> - 2019-03-19 05:11 -0700
                    Re: Use of goto in high-level C programming "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2019-03-19 20:13 +0800
                      Re: Use of goto in high-level C programming fir is a sexy shemale <cdalten@gmail.com> - 2019-03-19 05:42 -0700
                        Re: Use of goto in high-level C programming "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2019-03-19 20:44 +0800
                      Re: Use of goto in high-level C programming Wouter Verhelst <w@uter.be> - 2019-03-20 08:16 +0200
                        Re: Use of goto in high-level C programming "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2019-03-20 19:16 +0800
                Re: Telling Fred where to go... (Was: [ On topic, amazingtly ]: labels and declarations) fir is a sexy shemale <cdalten@gmail.com> - 2019-03-19 05:13 -0700
                  Re: Telling Fred where to go... (Was: [ On topic, amazingtly ]: labels and declarations) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-19 05:56 -0700
                    Re: Telling Fred where to go... (Was: [ On topic, amazingtly ]: labels and declarations) fir is a sexy shemale <cdalten@gmail.com> - 2019-03-19 06:30 -0700
                      Re: Telling Fred where to go... (Was: [ On topic, amazingtly ]: labels and declarations) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-19 06:54 -0700
                        Re: Telling Fred where to go... (Was: [ On topic, amazingtly ]: labels and declarations) fir is a sexy shemale <cdalten@gmail.com> - 2019-03-19 07:12 -0700
                          Re: Telling Fred where to go... (Was: [ On topic, amazingtly ]: labels and declarations) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-19 12:03 -0700
                            Re: Telling Fred where to go... (Was: [ On topic, amazingtly ]: labels and declarations) fir is a sexy shemale <cdalten@gmail.com> - 2019-03-19 13:33 -0700
    Re: [ On topic, amazingtly ]: labels and declarations fir is a sexy shemale <cdalten@gmail.com> - 2019-03-19 05:17 -0700
      Re: from programming to religion and then.... sex? "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2019-03-19 20:23 +0800
        Re: from programming to religion and then.... sex? fir is a sexy shemale <cdalten@gmail.com> - 2019-03-19 05:40 -0700
          Re: from programming to religion and then.... sex? "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2019-03-19 20:46 +0800
            Re: from programming to religion and then.... sex? fir is a sexy shemale <cdalten@gmail.com> - 2019-03-19 06:30 -0700
              Re: from programming to religion and then.... sex? "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2019-03-19 21:36 +0800
                Re: from programming to religion and then.... sex? fir is a sexy shemale <cdalten@gmail.com> - 2019-03-19 07:08 -0700
                  Re: from programming to religion and then.... sex? "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2019-03-20 19:16 +0800
    Re: [ On topic, amazingtly ]: labels and declarations John Bode <jfbode1029@gmail.com> - 2019-03-19 14:58 -0700

Page 1 of 6  [1] 2 3 4 5 6  Next page →

#141995 — [ On topic, amazingtly ]: labels and declarations

Came across something interesting the other day.  First of all, for the
purposes of this discussion, assume two things:
    1) You don't have any ideological objection to gotos.
    2) You don't have any ideological objection to C99 style "intermixing".

So, assume you like to have your declarations as close to the code that
uses hem as possible.  So, you write something like:

...
goto somelabel;
...


somelabel:
    int foo;
(code that uses foo)

But the compiler says that labels can only be associated with statements
and declarations aren't statements.  Makes sense, so you change the label
line to:

somelabel:;

and everything is fine.

Is this the approved fix?  Should it be necessary?  Is there any reason not
to do this?

-- 
The randomly chosen signature file that would have appeared here is more than 4
lines long.  As such, it violates one or more Usenet RFCs.  In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
	http://user.xmission.com/~gazelle/Sigs/CLCtopics

[toc] | [next] | [standalone]

#141996

On Sun, 17 Mar 2019 14:45:29 -0000 (UTC), gazelle@shell.xmission.com
(Kenny McCormack) wrote:

>Came across something interesting the other day.  First of all, for the
>purposes of this discussion, assume two things:
>    1) You don't have any ideological objection to gotos.
>    2) You don't have any ideological objection to C99 style "intermixing".
>
>So, assume you like to have your declarations as close to the code that
>uses hem as possible.  So, you write something like:
>
>...
>goto somelabel;
>...
>
>
>somelabel:
>    int foo;
>(code that uses foo)
>
>But the compiler says that labels can only be associated with statements
>and declarations aren't statements.  Makes sense, so you change the label
>line to:
>
>somelabel:;
>
>and everything is fine.
>
>Is this the approved fix?  Should it be necessary?  Is there any reason not
>to do this?

Well...if it works, it works, but I think only in the sense that
you've already gone so far off into the weeds that you might as well
keep going to see what's out there. But I wouldn't put it in
production code.

[toc] | [prev] | [next] | [standalone]

#141997

Would Jesus approve of this?

[toc] | [prev] | [next] | [standalone]

#141998

Kenny McCormack wrote:

> Came across something interesting the other day.  First of all, for the
> purposes of this discussion, assume two things:
>     1) You don't have any ideological objection to gotos.
>     2) You don't have any ideological objection to C99 style
>     "intermixing".
> 
> So, assume you like to have your declarations as close to the code that
> uses hem as possible.  So, you write something like:
> 
> ...
> goto somelabel;
> ...
> 
> 
> somelabel:
>     int foo;
> (code that uses foo)
> 
> But the compiler says that labels can only be associated with statements
> and declarations aren't statements.  Makes sense, so you change the label
> line to:
> 
> somelabel:;
> 
> and everything is fine.
> 
> Is this the approved fix?

I don't know about "approved", but it is consistant with the rules of the 
language[1], and (at least in the draft C11 document) is used as an example 
of a labeled null statement[2] .

[1] 6.8 "Statements and blocks", paragraph 1,
    6.8.1 "Labeled Statements", paragraphs 1, 4,
    6.8.3 "Expressions and null statements", paragraphs 1, 3
[2] 6.8.3 "Expressions and null Statements", paragraph 6 "Example 3"

> Should it be necessary?

According to the standard, yes. My personal opinion is that, since C99, 
declarations have become statement-like (in that they now specify "an action 
to be performed"; the (possibly conditional and code-path dependant) 
declaration of an object or objects[3]), and thus /should/ be permitted to 
carry a label.

[3] There was a recent conversation here ("...the value 
becomes,indeterminate each time the declaration is reached") on storage 
duration of objects, and their state wrt execution sequence and "jumps". 
Consider the example:
  {
    int a, b = 20;
    for (a = 10; a > 0 ; a--)
    {
      if (a%2) goto past;
      int b = a;
      past: if (b == a) puts("success");
    }
  }
the declaration and initialization of <<b>> is now an "action to be 
performed", based on the value of <<a>>. In C, prior to C99, this could not 
have happened, as conforming code would be obliged to declare and initialize 
that second <<b>> first, before the remainder of the block was executed:
  {
    int a, b = 20;
    for (a = 10; a > 0 ; a--)
    {
      int b = a;	/* REQUIRED TO PRECEDE STATEMENTS */
      if (a%2) goto past;
      past: if (b == a) puts("success");
    }
  }

Thus, my opinion: the code flow is influenced by the placement of the 
declaration, making the declaration "an action to be performed", and thus 
(conceptually) qualified to accept a label.

> Is there any reason not to do this?

According to the C standards? None that I can find. According to "shop 
standards", probably, at least in those shops that have an aversion to 
"goto" in the first place.

-- 
Lew Pitcher
"In Skills, We Trust"

[toc] | [prev] | [next] | [standalone]

#142001

On 3/17/19 2:16 PM, Lew Pitcher wrote:
> According to the standard, yes. My personal opinion is that, since C99, 
> declarations have become statement-like (in that they now specify "an action 
> to be performed"; the (possibly conditional and code-path dependant) 
> declaration of an object or objects[3]), and thus /should/ be permitted to 
> carry a label.

I looked at the grammer, and realized that the simplest way to do this:

* Change the production declaration to the now be named
declaration-statement (and moving all the pieces of declaration)

* Adding the new declaration-statement to be one of the options for a
statement

* Changing the definition of block-list to be:
statement
block-item-list statement

(i.e. using statement instead of block-item which is a decclaration or a
statement since that is now just a statement).


This unfortunately leads to the following being grammatically correct:

if(flag) int x;

which would mean that the following code might be valid or not depending
of if flag was true at run time, or

if(flag) int x;
else     float x;

where the type of x changes at run time, or even

for(int i=1; i < n; i++) int array[i];

so we possible execute multiple copies (or none) at a given point.

We can't just change a label-statement to allow a block-item (a
declaration or a statement) as then we get in the same issue with things
like

if(flag) label: int x;

The issue is that currently, the way a statement isn't a declaration,
means that declarations can't be used directly in control/conditional
statements, but only via a compound-statement, which introduces a scope,
so the declarations can't 'leak out'.

To allow a label on a declaration, wold require adding a layer to the
definition of the declaration production to allow it to be proceeded by
a label, in effect adding a declaration-statement that can be either

declaration
label: declaration-statement

and changing a block-item to be a declaration-statement of a statement,
and then something so that gotos can refer to either type of label.

It may be that because just adding the ; to put in a null-statement
provides the needed functionality, there wasn't enough needed for the
extra grammar.

[toc] | [prev] | [next] | [standalone]

#142002

On 17/03/2019 22:43, Richard Damon wrote:
> On 3/17/19 2:16 PM, Lew Pitcher wrote:
>> According to the standard, yes. My personal opinion is that, since C99,
>> declarations have become statement-like (in that they now specify "an action
>> to be performed"; the (possibly conditional and code-path dependant)
>> declaration of an object or objects[3]), and thus /should/ be permitted to
>> carry a label.
> 
> I looked at the grammer, and realized that the simplest way to do this:
> 
> * Change the production declaration to the now be named
> declaration-statement (and moving all the pieces of declaration)
> 
> * Adding the new declaration-statement to be one of the options for a
> statement
> 
> * Changing the definition of block-list to be:
> statement
> block-item-list statement
> 
> (i.e. using statement instead of block-item which is a decclaration or a
> statement since that is now just a statement).
> 
> 
> This unfortunately leads to the following being grammatically correct:
....
> The issue is that currently, the way a statement isn't a declaration,
> means that declarations can't be used directly in control/conditional
> statements, but only via a compound-statement, which introduces a scope,
> so the declarations can't 'leak out'.


How about just allowing a label to be statement by itself? You should be 
able to do:

   {s1; goto L1; s2; s3; L1:}

without requiring L1 to be followed by a dummy statement.

[toc] | [prev] | [next] | [standalone]

#142009

On 17/03/2019 22:55, Bart wrote:

> How about just allowing a label to be statement by itself? You should be 
> able to do:
> 
>    {s1; goto L1; s2; s3; L1:}
> 
> without requiring L1 to be followed by a dummy statement.

I tried that in my C compiler, and it was easier than I thought: it just 
needed two lines deleted!

That's subject to further tests, but it allows the above example (label 
immediately before "}") as well as the OP's example.

Labels now behave as they have always done in my own languages.

(As a small bonus, because labels are no longer recursively defined, the 
number of consecutive labels is no longer limited by stack space, but by 
heap (typically 1000 times bigger), and will fail more gracefully. 
Although this would affect very few (ie. zero) real programs.)

So, how long has it been now, 47 years that C programmers (and code 
generators) have been inconvenienced by the special quirks regarding 
labels? All because of a 1-minute fix.

[toc] | [prev] | [next] | [standalone]

#142010

Bart <bc@freeuk.com> writes:

>> [..allowing labels on declarations..] 
>
> How about just allowing a label to be statement by itself?

Not workable for C because it breaks existing code.

[toc] | [prev] | [next] | [standalone]

#142017

On 18/03/2019 03:46, Tim Rentsch wrote:
> Bart <bc@freeuk.com> writes:
> 
>>> [..allowing labels on declarations..] 
>>
>> How about just allowing a label to be statement by itself?
> 
> Not workable for C because it breaks existing code.
> 

Would it break much?  It would break this:

	if (x) L1: foo();

Do you think there is much existing code that would go wrong if labels
were made statements?  Apart from case labels (obviously), labels and
gotos are mostly used to break out of nested loops or handle error
conditions, and these should be fine.

(Of course, the fact that this change could break any existing code at
all is enough to give strong resistance to it - I am not suggesting that
it's okay as long as it doesn't break much!)

[toc] | [prev] | [next] | [standalone]

#142019

On 18/03/2019 07:41, David Brown wrote:
> On 18/03/2019 03:46, Tim Rentsch wrote:
>> Bart <bc@freeuk.com> writes:
>>
>>>> [..allowing labels on declarations..]
>>>
>>> How about just allowing a label to be statement by itself?
>>
>> Not workable for C because it breaks existing code.
>>
> 
> Would it break much?  It would break this:
> 
> 	if (x) L1: foo();
> 
> Do you think there is much existing code that would go wrong if labels
> were made statements?  Apart from case labels (obviously), labels and
> gotos are mostly used to break out of nested loops or handle error
> conditions, and these should be fine.
> 
> (Of course, the fact that this change could break any existing code at
> all is enough to give strong resistance to it - I am not suggesting that
> it's okay as long as it doesn't break much!)

Such examples (conditional blocks consisting of one label statement) are 
easily detected, and can be fixed, eg. by writing:

     if (x) {L1: foo();}

[toc] | [prev] | [next] | [standalone]

#142020

On Monday, March 18, 2019 at 7:20:17 AM UTC-4, Bart wrote:
> > 	if (x) L1: foo();
> 
> Such examples (conditional blocks consisting of one label statement) are 
> easily detected, and can be fixed, eg. by writing:
> 
>      if (x) {L1: foo();}

Add an exception to the statement rule:  if the branch target
is a label which is also the entry point of a block, then the
label behaves as it did previously, unless the label is explicitly
followed by a semicolon.

Would NOT break functionality:
    if (x) L1: foo();

Would break functionality:
    if (x) L1:; foo();

-- 
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#142021

On 18/03/2019 11:39, Rick C. Hodgin wrote:
> On Monday, March 18, 2019 at 7:20:17 AM UTC-4, Bart wrote:
>>> 	if (x) L1: foo();
>>
>> Such examples (conditional blocks consisting of one label statement) are
>> easily detected, and can be fixed, eg. by writing:
>>
>>       if (x) {L1: foo();}
> 
> Add an exception to the statement rule:  if the branch target
> is a label which is also the entry point of a block, then the
> label behaves as it did previously, unless the label is explicitly
> followed by a semicolon.
> 
> Would NOT break functionality:
>      if (x) L1: foo();
> 
> Would break functionality:
>      if (x) L1:; foo();

I don't understand the point of the rule. Which of those is the original 
code; which is the new code that it has to be modified to?

If existing code has:

     if (x) L1:; foo();

then that's a pointless bit of code, and foo() is called unconditionally.

In my revised compiler, this would be called out, and for good reason.

On the other hand, existing code like this:

     if (x) L1: foo();

is valid, with foo() conditional, but incompatible with labels being 
independent statements. Since conditional label statements are 
meaningless, the fix in this case is to write:

     if (x) {L1: foo();}

The fix for 'if (x) L1:;', would be to just write 'L1:', but if someone 
really does want to keep the 'if (x)' then this will do it:

     if (x) {L1:}

[toc] | [prev] | [next] | [standalone]

#142023

On Monday, March 18, 2019 at 8:08:49 AM UTC-4, Bart wrote:
> On 18/03/2019 11:39, Rick C. Hodgin wrote:
> > On Monday, March 18, 2019 at 7:20:17 AM UTC-4, Bart wrote:
> >>> 	if (x) L1: foo();
> >>
> >> Such examples (conditional blocks consisting of one label statement) are
> >> easily detected, and can be fixed, eg. by writing:
> >>
> >>       if (x) {L1: foo();}
> > 
> > Add an exception to the statement rule:  if the branch target
> > is a label which is also the entry point of a block, then the
> > label behaves as it did previously, unless the label is explicitly
> > followed by a semicolon.
> > 
> > Would NOT break functionality:
> >      if (x) L1: foo();
> > 
> > Would break functionality:
> >      if (x) L1:; foo();
> 
> I don't understand the point of the rule. Which of those is the original 
> code; which is the new code that it has to be modified to?

The goal of the rule is to not break any existing code.  By adding
the rule I suggest, no existing code breaks (to my knowledge).

> If existing code has:
>      if (x) L1:; foo();
> 
> then that's a pointless bit of code, and foo() is called unconditionally.

It is.  I think that's the point.  The only time you'd want that
type of code to work is when L1: is a target to run foo(), and
foo() is the target if the if (x) branch entry.

However, having the L1:; ability would allow it to be used to
create a target that could have a breakpoint added to it, for
example.  It would require the compiler to inject a NOP there,
but it is doable

> In my revised compiler, this would be called out, and for good reason.
> 
> On the other hand, existing code like this:
> 
>      if (x) L1: foo();
> 
> is valid, with foo() conditional, but incompatible with labels being 
> independent statements.

Correct.  That's why I propose the new rule on labels being
statements.

> Since conditional label statements are 
> meaningless, the fix in this case is to write:
> 
>      if (x) {L1: foo();}
> 
> The fix for 'if (x) L1:;', would be to just write 'L1:', but if someone 
> really does want to keep the 'if (x)' then this will do it:
> 
>      if (x) {L1:}

It's one workaround.  By adding the rule that labels which are
also the entry points of flow control targets behave as they
always have, and that if you want the new functionality there
you have to use the L1:; syntax, it would not break any existing
code (it may still break other code, but I can't think of any).

I've always thought labels that are on stand-alone lines should
inject a NOP statement and be a breakpoint target in a debugger:

        if (x)
            goto target;

        // Other code here

    target:
        next_thing();

However, when they are like this, the breakpoint should not go
on the branch, but on the the next thing:

                if (x)
                    goto target;

                // Other code here

    target:     next_thing();

Just a thought.  Always made sense to me to allow breakpoints
on target locations, including entry { and exit } locations.
I added the idea of horizontal breakpoints to my debugger for
this purpose as well, meaning you put a breakpoint at a horizontal
point in a source code line, statement, or expression.  When flow
gets to that point in the middle of its normal processing, rather
than just on a line, it would break.

-- 
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#142025 — labels and declarations and debugger breakpoints

On Monday, March 18, 2019 at 8:26:48 AM UTC-4, Rick C. Hodgin wrote:
> I've always thought labels that are on stand-alone lines should
> inject a NOP statement and be a breakpoint target in a debugger:

I should add that this is only when compiling in debug mode.  When
compiling an optimized runtime for performance, the NOPs would not
be injected.

> 
>         if (x)
>             goto target;
> 
>         // Other code here
> 
>     target:
>         next_thing();
> 
> However, when they are like this, the breakpoint should not go
> on the branch, but on the the next thing:
> 
>                 if (x)
>                     goto target;
> 
>                 // Other code here
> 
>     target:     next_thing();
> 
> Just a thought.  Always made sense to me to allow breakpoints
> on target locations, including entry { and exit } locations.
> I added the idea of horizontal breakpoints to my debugger for
> this purpose as well, meaning you put a breakpoint at a horizontal
> point in a source code line, statement, or expression.  When flow
> gets to that point in the middle of its normal processing, rather
> than just on a line, it would break.

-- 
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#142040

On 18/03/2019 12:26, Rick C. Hodgin wrote:
> On Monday, March 18, 2019 at 8:08:49 AM UTC-4, Bart wrote:
>> On 18/03/2019 11:39, Rick C. Hodgin wrote:
>>> On Monday, March 18, 2019 at 7:20:17 AM UTC-4, Bart wrote:
>>>>> 	if (x) L1: foo();
>>>>
>>>> Such examples (conditional blocks consisting of one label statement) are
>>>> easily detected, and can be fixed, eg. by writing:
>>>>
>>>>        if (x) {L1: foo();}
>>>
>>> Add an exception to the statement rule:  if the branch target
>>> is a label which is also the entry point of a block, then the
>>> label behaves as it did previously, unless the label is explicitly
>>> followed by a semicolon.
>>>
>>> Would NOT break functionality:
>>>       if (x) L1: foo();
>>>
>>> Would break functionality:
>>>       if (x) L1:; foo();
>>
>> I don't understand the point of the rule. Which of those is the original
>> code; which is the new code that it has to be modified to?
> 
> The goal of the rule is to not break any existing code.  By adding
> the rule I suggest, no existing code breaks (to my knowledge).
> 
>> If existing code has:
>>       if (x) L1:; foo();
>>
>> then that's a pointless bit of code, and foo() is called unconditionally.
> 
> It is.  I think that's the point.  The only time you'd want that
> type of code to work is when L1: is a target to run foo(), and
> foo() is the target if the if (x) branch entry.
> 
> However, having the L1:; ability would allow it to be used to
> create a target that could have a breakpoint added to it, for
> example.  It would require the compiler to inject a NOP there,
> but it is doable
> 
>> In my revised compiler, this would be called out, and for good reason.
>>
>> On the other hand, existing code like this:
>>
>>       if (x) L1: foo();
>>
>> is valid, with foo() conditional, but incompatible with labels being
>> independent statements.
> 
> Correct.  That's why I propose the new rule on labels being
> statements.
> 
>> Since conditional label statements are
>> meaningless, the fix in this case is to write:
>>
>>       if (x) {L1: foo();}
>>
>> The fix for 'if (x) L1:;', would be to just write 'L1:', but if someone
>> really does want to keep the 'if (x)' then this will do it:
>>
>>       if (x) {L1:}
> 
> It's one workaround.  By adding the rule that labels which are
> also the entry points of flow control targets behave as they
> always have, and that if you want the new functionality there
> you have to use the L1:; syntax, it would not break any existing
> code (it may still break other code, but I can't think of any).

We're trying to get away from having to sometimes write L1:;

There should be no new rules to consider (actually I still don't get 
what you wrote above, nor what you wrote later).

Instead of a label marking the following statement, it marks a point in 
the execution path. So it will operate exactly the same as before, 
except that (1) you don't need the ";" in "L:;}" and (2) what had been a 
single statement 'L:S;' following 'if' or 'else' needs to be wrapped in 
{...}, but that is easily detected.

[toc] | [prev] | [next] | [standalone]

#142042

In article <lwQjE.545331$OGY.30805@fx08.am4>, Bart  <bc@freeuk.com> wrote:
...
>We're trying to get away from having to sometimes write L1:;

Indeed.  And I would make the argument that this is an instance where,
rather than issue an error message and fail to compile, the compiler should
just (silently) insert the ; for you and continue on.  This is one of those
(rare) cases where it is unambiguous what the fix is, so the compiler
should just do it.  I grant both of the following caveats:

    1) This is against the general "do what I say" rather than "do what I mean"
	nature/culture of C.

    2) Cases like this are rare; I'm not arguing for a general policy of
	the compiler fixing things for you, but in this case, it is
	unambiguous, so it could (should?) easily be done.

-- 
Just remember:

    Pence is all the evil, with none of the crazy.

[toc] | [prev] | [next] | [standalone]

#142051

On 18/03/2019 19:11, Kenny McCormack wrote:
> In article <lwQjE.545331$OGY.30805@fx08.am4>, Bart  <bc@freeuk.com> wrote:
> ...
>> We're trying to get away from having to sometimes write L1:;
> 
> Indeed.  And I would make the argument that this is an instance where,
> rather than issue an error message and fail to compile, the compiler should
> just (silently) insert the ; for you and continue on.  This is one of those
> (rare) cases where it is unambiguous what the fix is, so the compiler
> should just do it.

That is another way of doing it, which keeps things backwards-compatible 
(although it's a little trickier to do).

The problem with both approaches (make labels independent, or silently 
assume a hidden ";") is that a program that works with one compiler, 
will not work with another which doesn't do that fix.

[toc] | [prev] | [next] | [standalone]

#142043

On Monday, March 18, 2019 at 1:25:48 PM UTC-4, Bart wrote:
> On 18/03/2019 12:26, Rick C. Hodgin wrote:
> > On Monday, March 18, 2019 at 8:08:49 AM UTC-4, Bart wrote:
> >> On 18/03/2019 11:39, Rick C. Hodgin wrote:
> >>> On Monday, March 18, 2019 at 7:20:17 AM UTC-4, Bart wrote:
> >>>>> 	if (x) L1: foo();
> >>>>
> >>>> Such examples (conditional blocks consisting of one label statement) are
> >>>> easily detected, and can be fixed, eg. by writing:
> >>>>
> >>>>        if (x) {L1: foo();}
> >>>
> >>> Add an exception to the statement rule:  if the branch target
> >>> is a label which is also the entry point of a block, then the
> >>> label behaves as it did previously, unless the label is explicitly
> >>> followed by a semicolon.
> >>>
> >>> Would NOT break functionality:
> >>>       if (x) L1: foo();
> >>>
> >>> Would break functionality:
> >>>       if (x) L1:; foo();
> >>
> >> I don't understand the point of the rule. Which of those is the original
> >> code; which is the new code that it has to be modified to?
> > 
> > The goal of the rule is to not break any existing code.  By adding
> > the rule I suggest, no existing code breaks (to my knowledge).
> > 
> >> If existing code has:
> >>       if (x) L1:; foo();
> >>
> >> then that's a pointless bit of code, and foo() is called unconditionally.
> > 
> > It is.  I think that's the point.  The only time you'd want that
> > type of code to work is when L1: is a target to run foo(), and
> > foo() is the target if the if (x) branch entry.
> > 
> > However, having the L1:; ability would allow it to be used to
> > create a target that could have a breakpoint added to it, for
> > example.  It would require the compiler to inject a NOP there,
> > but it is doable
> > 
> >> In my revised compiler, this would be called out, and for good reason.
> >>
> >> On the other hand, existing code like this:
> >>
> >>       if (x) L1: foo();
> >>
> >> is valid, with foo() conditional, but incompatible with labels being
> >> independent statements.
> > 
> > Correct.  That's why I propose the new rule on labels being
> > statements.
> > 
> >> Since conditional label statements are
> >> meaningless, the fix in this case is to write:
> >>
> >>       if (x) {L1: foo();}
> >>
> >> The fix for 'if (x) L1:;', would be to just write 'L1:', but if someone
> >> really does want to keep the 'if (x)' then this will do it:
> >>
> >>       if (x) {L1:}
> > 
> > It's one workaround.  By adding the rule that labels which are
> > also the entry points of flow control targets behave as they
> > always have, and that if you want the new functionality there
> > you have to use the L1:; syntax, it would not break any existing
> > code (it may still break other code, but I can't think of any).
> 
> We're trying to get away from having to sometimes write L1:;
> 
> There should be no new rules to consider (actually I still don't get 
> what you wrote above, nor what you wrote later).
> 
> Instead of a label marking the following statement, it marks a point in 
> the execution path. So it will operate exactly the same as before, 
> except that (1) you don't need the ";" in "L:;}" and (2) what had been a 
> single statement 'L:S;' following 'if' or 'else' needs to be wrapped in 
> {...}, but that is easily detected.

I misunderstood.  I thought the goal was to make L1: a statement in
and of itself.  My statement was that if that's the intent, it should
have a fallback for cases where it's used with the label target that
corresponds as the entry point of a flow control block, in which case
you could make it a statement using L1:;.

Making L1: a statement would break the existing code:

        if (x)
    L1:
            code();

It would make it be effectively:

    if (x)
        L1:;

    code();

It's different.  My argument was, leave L1: alone in the case
where it is the same as the first line of an entry into a flow
control block, and add the extension that if you want that label
at that place to be its own statement as it would be everywhere
else, you must use L1:;.

If it's a non-issue it's a non-issue.  It wouldn't be the first
thing I misunderstood when reading it. :-)

-- 
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#142044

On 18/03/2019 19:31, Rick C. Hodgin wrote:
> On Monday, March 18, 2019 at 1:25:48 PM UTC-4, Bart wrote:

>> Instead of a label marking the following statement, it marks a point in
>> the execution path. So it will operate exactly the same as before,
>> except that (1) you don't need the ";" in "L:;}" and (2) what had been a
>> single statement 'L:S;' following 'if' or 'else' needs to be wrapped in
>> {...}, but that is easily detected.
> 
> I misunderstood.  I thought the goal was to make L1: a statement in
> and of itself.

Yes, that will let be L1: be independent of any following statements, 
and effectively mark any point in the path.

> My statement was that if that's the intent, it should
> have a fallback for cases where it's used with the label target that
> corresponds as the entry point of a flow control block, in which case
> you could make it a statement using L1:;.

I don't get this paragraph. L1: in a revised compiler will always be a 
statement (although a non-executable one).

> Making L1: a statement would break the existing code:
> 
>          if (x)
>      L1:
>              code();
> 
> It would make it be effectively:
> 
>      if (x)
>          L1:;
> 
>      code();

That's my case (2).


> It's different.  My argument was, leave L1: alone in the case
> where it is the same as the first line of an entry into a flow
> control block, and add the extension that if you want that label
> at that place to be its own statement as it would be everywhere
> else, you must use L1:;.

You mean, still having L1 tied to a following statement when it would 
otherwise split L1:S1 into two statements?

I think that would make things too complex. Either L1 is a statement by 
itself or it isn't. It shouldn't only be independent in some cases and 
not in others. The rule should be unequivocal.

So L1:S1, which is anyway going to be extremely rare, needs to be 
written as {L1: S1;}.

This also ensures that, in new code, people are obliged to have to write:

   if (C) {L1: S1;}

rather than relying on an odd fall-back rule, generating yet more code 
that relies on it so ensuring you can never get rid of the rule, AND 
adding yet another quirk to the language!

[toc] | [prev] | [next] | [standalone]

#142045

On Monday, March 18, 2019 at 3:58:12 PM UTC-4, Bart wrote:
> On 18/03/2019 19:31, Rick C. Hodgin wrote:
> > On Monday, March 18, 2019 at 1:25:48 PM UTC-4, Bart wrote:
> 
> >> Instead of a label marking the following statement, it marks a point in
> >> the execution path. So it will operate exactly the same as before,
> >> except that (1) you don't need the ";" in "L:;}" and (2) what had been a
> >> single statement 'L:S;' following 'if' or 'else' needs to be wrapped in
> >> {...}, but that is easily detected.
> > 
> > I misunderstood.  I thought the goal was to make L1: a statement in
> > and of itself.
> 
> Yes, that will let be L1: be independent of any following statements, 
> and effectively mark any point in the path.
> 
> > My statement was that if that's the intent, it should
> > have a fallback for cases where it's used with the label target that
> > corresponds as the entry point of a flow control block, in which case
> > you could make it a statement using L1:;.
> 
> I don't get this paragraph. L1: in a revised compiler will always be a 
> statement (although a non-executable one).
> 
> > Making L1: a statement would break the existing code:
> > 
> >          if (x)
> >      L1:
> >              code();
> > 
> > It would make it be effectively:
> > 
> >      if (x)
> >          L1:;
> > 
> >      code();
> 
> That's my case (2).
> 
> > It's different.  My argument was, leave L1: alone in the case
> > where it is the same as the first line of an entry into a flow
> > control block, and add the extension that if you want that label
> > at that place to be its own statement as it would be everywhere
> > else, you must use L1:;.
> 
> You mean, still having L1 tied to a following statement when it would 
> otherwise split L1:S1 into two statements?

Yes.  That way it won't break any existing functionality.

> I think that would make things too complex. Either L1 is a statement by 
> itself or it isn't. It shouldn't only be independent in some cases and 
> not in others. The rule should be unequivocal.

It would be unequivocal, but it would be two different operations.
(1) stand-alone label
(2) label that's the entry point of a flow control block

In the case of (2) it simply identifies the serves as a placeholder
which points to the next statement within.

> So L1:S1, which is anyway going to be extremely rare, needs to be 
> written as {L1: S1;}.

I agree that it is rare.  I don't think it exists in most code, but
it could exist.  And I don't agree with the solution of forcing
developers to create { this; solution; }.  I would rather not break
existing code, so by creating the (1) and (2) breakout above, no
existing code would break (at least none that I can think of right
now).

> This also ensures that, in new code, people are obliged to have to write:
> 
>    if (C) {L1: S1;}
> 
> rather than relying on an odd fall-back rule, generating yet more code 
> that relies on it so ensuring you can never get rid of the rule, AND 
> adding yet another quirk to the language!

I don't think I've ever written code using a label in a conditional
block of code like that where I didn't already enclose it in curly
braces ... simply because this looks better:

        if (x)
        {
    L1:
            code();
        }

than this:

        if (x)
    L1:
            code();

And I can't even imagine a case where I would use:

        if (x) L1: code();

Is that even legal? :-)  Anyone writing code like that (that's not
part of a code generator) ... I don't know what to say.

-- 
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

Page 1 of 6  [1] 2 3 4 5 6  Next page →

Back to top | Article view | comp.lang.c

csiph-web