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 4 of 6 — ← Prev page 1 2 3 [4] 5 6  Next page →

#142298

On 3/22/2019 7:13 PM, Keith Thompson wrote:
> Manfred <noname@add.invalid> writes:
>> On 3/22/2019 4:22 AM, Robert Wessel wrote:
>>>> This problem apparently follows from labels being neither statements nor
>>>> declarations, but instead entities of their own slapped into the
>>>> language to pair their ASM counterparts.
>>>> Today one may say they were not thought well enough in the beginning,
>>>> but considering the status of CS in the '70s it would have been probably
>>>> hard to foresee this kind of implications at the time, and hey, they
>>>> served the purpose so far.
>>>
>>> Labels are an optional prefix to a statement.
>>
>> i.e. a direct import from ASM, without further attempt for integration
>> with the language structure.
> 
> Not really.  The syntax and semantics of C's labels are similar to those
> of assembly language labels, but I'm not sure how else you'd define
> them.  There's not much you could do to integrate them more closely into
> the rest of the language.  Their syntax is defined using the same BNF as
> everything else:
> 
>      labeled-statement:
>          identifier : statement
>          case constant-expression : statement
>          default : statement

BNF describes the design choices of the language, it does not mean that 
such design is good.
Here it is shown that a label is defined to be part of a kind of 
statement - a labeled-statement.
This means that:
1) The definition of statement had to be augmented with an additional 
type thereof: a labeled-statement
2) To allow for fitting this assembly-like entity.

Considering that the main building blocks of the C syntax are 
Declarations and Statements, the adopted choice /may/ [*] be seen as 
poor integration in that it does not fit labels into any of these, but 
instead the language lawmakers had to make a special kind of statement 
to allow for its insertion.
To me this hints some lack of uniformity in the language design.
On the other hand, the absence of a 'labeled-declaration' may show some 
lack of symmetry in the same design.

With a-posteriori knowledge, and after four decades of CS evolution, 
this choice appears to clash with a more modern C, where declarations 
may make sense to be labeled too.
This may have been avoided either by defining a label as a 'null 
statement', so a type of statement by itself, as Bart was suggesting, 
or, after your display of the formal syntax, by envisioning the 
possibility for a 'labeled-declaration'

[*] All of this can be argued today, as said, after more than 40 years 
of C development, so it would make no sense to say that the current 
status was a poor choice in the design of the language, in particular 
considering /when/ the language was designed.
It may only hint to some possible better choice that could have been 
made, but that in fact did not hinder at all the success of the language 
itself.
Even more since the solution of adding a null statement like "label: ;" 
is pretty simple and concise.

> 
> Compare that to the preprocessor, which really isn't tightly integrated
> into the language structure.
> 

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

#142307

Manfred <noname@add.invalid> writes:
> On 3/22/2019 7:13 PM, Keith Thompson wrote:
>> Manfred <noname@add.invalid> writes:
>>> On 3/22/2019 4:22 AM, Robert Wessel wrote:
>>>>> This problem apparently follows from labels being neither statements nor
>>>>> declarations, but instead entities of their own slapped into the
>>>>> language to pair their ASM counterparts.
>>>>> Today one may say they were not thought well enough in the beginning,
>>>>> but considering the status of CS in the '70s it would have been probably
>>>>> hard to foresee this kind of implications at the time, and hey, they
>>>>> served the purpose so far.
>>>>
>>>> Labels are an optional prefix to a statement.
>>>
>>> i.e. a direct import from ASM, without further attempt for integration
>>> with the language structure.
>> 
>> Not really.  The syntax and semantics of C's labels are similar to those
>> of assembly language labels, but I'm not sure how else you'd define
>> them.  There's not much you could do to integrate them more closely into
>> the rest of the language.  Their syntax is defined using the same BNF as
>> everything else:
>> 
>>      labeled-statement:
>>          identifier : statement
>>          case constant-expression : statement
>>          default : statement
>
> BNF describes the design choices of the language, it does not mean that 
> such design is good.

Am I correct in thinking that your main objection is to the fact that a
declaration cannot be directly labeled?

> Here it is shown that a label is defined to be part of a kind of 
> statement - a labeled-statement.
> This means that:
> 1) The definition of statement had to be augmented with an additional 
> type thereof: a labeled-statement

The alternative would be to add a new label-statement production.
I don't see either as a problem.

> 2) To allow for fitting this assembly-like entity.

You keep calling it "assembly-like".  Which it is, I suppose,
but I see no particular reason for C and assembly language to
have substantially different syntax for labels.  Even in assembly,
eva label is an abstraction, not corresponding to any construct in
the generated machine code.

I suggest that the real point is that you don't like the syntax
of C labels (which is, of course, perfectly valid).  But I'll note
that, to the extent that assembly language has declarations, they
can be labelled.  For example, here's an excerpt from an assembly
listing generated by gcc (you could say that ".string" is a kind
of declaration).

.LC0:
        .string "Hello"

In that sense, if I understand you correctly, you want C's labels
to be *more* assembly-like.

Prior to C99, it wasn't possible to mix declarations and statements
within a block, and it wouldn't have made much sense to allow labels
on declarations (though I suppose it could have been permitted).
Both C and (much earlier) C++ were changed to allow mixed
declarations and statements.  C++ did it by defining a declaration
within a block as a declaration-statement; allowing labels on
declarations fell out of that.  C kept the distinction between
declarations and statements and added a new block-item production.

A side effect of the way C did this is that a label cannot
immediately precede a declaration.

The C99 Rationale doesn't even mention this.  I suspect that the
committee either didn't consider this, or decided it was trivial
and not worth addressing, particularly since it breaks no existing
code and is relevant only for code that uses goto statements.
The workaround, adding a null statement after the label, is easy
enough that a language fix is IMHO just not worth the effort.
(I've used that workaround myself, but I don't think I've ever done
so in code that wasn't deliberately obfuscated.)

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

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

#142418

On Saturday, March 23, 2019 at 2:58:05 PM UTC-4, Keith Thompson wrote:
...
> Prior to C99, it wasn't possible to mix declarations and statements
> within a block, and it wouldn't have made much sense to allow labels
> on declarations (though I suppose it could have been permitted).

In general, if you have any good reason to write:

    int var;
    label: var=expression;

Then it would be more convenient if we were allowed to write

    label: int var=expression;

for precisely the same reason that would apply if "label:" were removed
entirely. That would have been true even in C90, but the relaxation of
the restrictions on initializers in C99 would have made this issue more
likely to come up. I think that the main reason this hasn't been a big
issue is the unpopularity of labels in general.

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

#142436

James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On Saturday, March 23, 2019 at 2:58:05 PM UTC-4, Keith Thompson wrote:
> ...
>> Prior to C99, it wasn't possible to mix declarations and statements
>> within a block, and it wouldn't have made much sense to allow labels
>> on declarations (though I suppose it could have been permitted).
>
> In general, if you have any good reason to write:
>
>     int var;
>     label: var=expression;
>
> Then it would be more convenient if we were allowed to write
>
>     label: int var=expression;
>
> for precisely the same reason that would apply if "label:" were removed
> entirely. That would have been true even in C90, but the relaxation of
> the restrictions on initializers in C99 would have made this issue more
> likely to come up. I think that the main reason this hasn't been a big
> issue is the unpopularity of labels in general.

Agreed.  But if I wanted to write:

    label: int var = expression;

I'd just write:

    label:;
    int var = expression;

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

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

#142003

Richard Damon <Richard@Damon-Family.org> writes:
[...]
> 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
[...]

C++ allows this; a declaration (if it appears inside a function
defintion) is a kind of statement.  The scope of x is limited to the
declaration-statement, so the above is equivalent to:

    if (flag) { int x; }
    else      { float x; }

which is valid in C.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

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

#142004

Keith Thompson wrote:

> Richard Damon <Richard@Damon-Family.org> writes:
> [...]
>> 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
> [...]
> 
> C++ allows this; a declaration (if it appears inside a function
> defintion) is a kind of statement.  The scope of x is limited to the
> declaration-statement, so the above is equivalent to:
> 
>     if (flag) { int x; }
>     else      { float x; }
> 
> which is valid in C.

By implication, even current C supports this, afaict. Consider

  if (!flag) goto label1;
  int x;
  goto label2;
  label1: ;
  float x;
  label2: ;

Doesn't this accomplish the same end-state as Richard's
 if(flag) int x;
 else     float x;
?

-- 
Lew Pitcher
"In Skills, We Trust"

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

#142005

Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
> Keith Thompson wrote:
>> Richard Damon <Richard@Damon-Family.org> writes:
>> [...]
>>> 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
>> [...]
>> 
>> C++ allows this; a declaration (if it appears inside a function
>> defintion) is a kind of statement.  The scope of x is limited to the
>> declaration-statement, so the above is equivalent to:
>> 
>>     if (flag) { int x; }
>>     else      { float x; }
>> 
>> which is valid in C.
>
> By implication, even current C supports this, afaict. Consider
>
>   if (!flag) goto label1;
>   int x;
>   goto label2;
>   label1: ;
>   float x;
>   label2: ;
>
> Doesn't this accomplish the same end-state as Richard's
>  if(flag) int x;
>  else     float x;
> ?

No.  In your example with gotos, the declaration `float x;` is illegal,
because there's already an `x` defined in the same scope.

In Richard's example, if the scopes of the two `x`s extended beyond the
if-else statement, it would be difficult to define the semantics or,
more likely, the second declaration would be illegal for the same
reason.  If the scopes were defined as they are in C++, they would be
non-overlapping and unambiguous (and not useful, since nothing could
refer to either `x`).

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

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

#142006

Keith Thompson wrote:

> Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
>> Keith Thompson wrote:
>>> Richard Damon <Richard@Damon-Family.org> writes:
>>> [...]
>>>> 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
>>> [...]
>>> 
>>> C++ allows this; a declaration (if it appears inside a function
>>> defintion) is a kind of statement.  The scope of x is limited to the
>>> declaration-statement, so the above is equivalent to:
>>> 
>>>     if (flag) { int x; }
>>>     else      { float x; }
>>> 
>>> which is valid in C.
>>
>> By implication, even current C supports this, afaict. Consider
>>
>>   if (!flag) goto label1;
>>   int x;
>>   goto label2;
>>   label1: ;
>>   float x;
>>   label2: ;
>>
>> Doesn't this accomplish the same end-state as Richard's
>>  if(flag) int x;
>>  else     float x;
>> ?
> 
> No.  In your example with gotos, the declaration `float x;` is illegal,
> because there's already an `x` defined in the same scope.

Ahhh, that explains it. OK, I understand now.

> In Richard's example, if the scopes of the two `x`s extended beyond the
> if-else statement, it would be difficult to define the semantics or,
> more likely, the second declaration would be illegal for the same
> reason.  If the scopes were defined as they are in C++, they would be
> non-overlapping and unambiguous (and not useful, since nothing could
> refer to either `x`).
> 


-- 
Lew Pitcher
"In Skills, We Trust"

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

#142008

Keith Thompson <kst-u@mib.org> writes:

> Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
>
>> Keith Thompson wrote:
>>
>>> Richard Damon <Richard@Damon-Family.org> writes:
>>> [...]
>>>
>>>> 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
>>>
>>> [...]
>>>
>>> C++ allows this;  a declaration (if it appears inside a function
>>> defintion) is a kind of statement.  The scope of x is limited to the
>>> declaration-statement, so the above is equivalent to:
>>>
>>>     if (flag) { int x; }
>>>     else      { float x; }
>>>
>>> which is valid in C.
>>
>> By implication, even current C supports this, afaict.  Consider
>>
>>   if (!flag) goto label1;
>>   int x;
>>   goto label2;
>>   label1: ;
>>   float x;
>>   label2: ;
>>
>> Doesn't this accomplish the same end-state as Richard's
>>  if(flag) int x;
>>  else     float x;
>> ?
>
> No.  In your example with gotos, the declaration `float x;` is illegal,
> because there's already an `x` defined in the same scope.
>
> In Richard's example, if the scopes of the two `x`s extended beyond the
> if-else statement, it would be difficult to define the semantics or,
> more likely, the second declaration would be illegal for the same
> reason.  If the scopes were defined as they are in C++, they would be
> non-overlapping and unambiguous (and not useful, since nothing could
> refer to either `x`).

I think you (and also Richard Damon) are forgetting 6.8.4 p3
(already present in C99, though not in C90):

    A selection statement is a block whose scope is a strict
    subset of the scope of its enclosing block.  Each associated
    substatement is also a block whose scope is a strict subset
    of the scope of the selection statement.

The following program illustrates the behavior:

    typedef void keep_nitpickers_happy;

    int
    main( keep_nitpickers_happy ){
        if( 0 ) return  sizeof( enum { SCOPED = 3 });
        return  SCOPED != 3;
    }

This program is legal under C90, but 'SCOPED' is undeclared in
the final return statement under C99 or C11.

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

#142011

On 3/17/19 8:41 PM, Tim Rentsch wrote:
> Keith Thompson <kst-u@mib.org> writes:
>>
>> In Richard's example, if the scopes of the two `x`s extended beyond the
>> if-else statement, it would be difficult to define the semantics or,
>> more likely, the second declaration would be illegal for the same
>> reason.  If the scopes were defined as they are in C++, they would be
>> non-overlapping and unambiguous (and not useful, since nothing could
>> refer to either `x`).
> 
> I think you (and also Richard Damon) are forgetting 6.8.4 p3
> (already present in C99, though not in C90):
> 
>     A selection statement is a block whose scope is a strict
>     subset of the scope of its enclosing block.  Each associated
>     substatement is also a block whose scope is a strict subset
>     of the scope of the selection statement.
> 
I will admit that I hadn't followed the standards into that detail an
missed that they changed to make the statements implicit scopes.

With that changed, I am not sure if there is any particular difficulty
in changing the grammar so that declarations are fully a statement, and
thus could have a label in front of it.

The biggest issue that I can think of is this would likely move and
renumber all the requirements on Declarations (basically 6.7) to be
under Statements(6.8, which would then become 6.7 and 6.7 was moved),
probably after jump statements (6.8.6 now, 6.7.6 with the above
renumbering), so all 6.7.x numbers become 6.7.7.x, and 6.8.x becomes
6.7.x. and all the 6.x above 8 get renumbers a step lower.

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

#142013

Richard Damon <Richard@Damon-Family.org> writes:
> On 3/17/19 8:41 PM, Tim Rentsch wrote:
>> Keith Thompson <kst-u@mib.org> writes:
>>>
>>> In Richard's example, if the scopes of the two `x`s extended beyond the
>>> if-else statement, it would be difficult to define the semantics or,
>>> more likely, the second declaration would be illegal for the same
>>> reason.  If the scopes were defined as they are in C++, they would be
>>> non-overlapping and unambiguous (and not useful, since nothing could
>>> refer to either `x`).
>> 
>> I think you (and also Richard Damon) are forgetting 6.8.4 p3
>> (already present in C99, though not in C90):
>> 
>>     A selection statement is a block whose scope is a strict
>>     subset of the scope of its enclosing block.  Each associated
>>     substatement is also a block whose scope is a strict subset
>>     of the scope of the selection statement.
>> 
> I will admit that I hadn't followed the standards into that detail an
> missed that they changed to make the statements implicit scopes.
>
> With that changed, I am not sure if there is any particular difficulty
> in changing the grammar so that declarations are fully a statement, and
> thus could have a label in front of it.
>
> The biggest issue that I can think of is this would likely move and
> renumber all the requirements on Declarations (basically 6.7) to be
> under Statements(6.8, which would then become 6.7 and 6.7 was moved),
> probably after jump statements (6.8.6 now, 6.7.6 with the above
> renumbering), so all 6.7.x numbers become 6.7.7.x, and 6.8.x becomes
> 6.7.x. and all the 6.x above 8 get renumbers a step lower.

In the 2011 C++ standard, section 6 is Statements, section 7 is
Declarations, and section 6.7 is Declaration statements.

Not all declarations are statements in C++, only those that appear
in a context that permits a statement.

I don't think that treating declarations as statements would require
any radical changes to the C standard, but I don't think it would
be worth doing.  I'm not aware of any significant problems that
it would solve.  (Having to add a semicolon after a label in some
contexts is not, in my opinion, a significant problem.)

(Just a reminder: Tim Rentsch is still in my killfile, so don't infer
anything if I don't respond to something he writes.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

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

#142014

Keith Thompson <kst-u@mib.org> writes:

> (Just a reminder:  Tim Rentsch is still in my killfile, so don't
> infer anything if I don't respond to something he writes.)

A note of explanation - after he killfiled me sometime last
August, I got the impression Keith had taken me out of his
killfile when he responded to a posting of mine sometime
in December.  My response to his posting in this thread
was written in the belief that he would see it normally.
Sorry for any confusion.

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

#142015

In article <8636nkre0s.fsf@mailhub.linuxsc.com>,
Tim Rentsch  <tr.17687@z991.linuxsc.com> wrote:
>Keith Thompson <kst-u@mib.org> writes:
>
>> (Just a reminder:  Tim Rentsch is still in my killfile, so don't
>> infer anything if I don't respond to something he writes.)
>
>A note of explanation - after he killfiled me sometime last
>August, I got the impression Keith had taken me out of his
>killfile when he responded to a posting of mine sometime
>in December.  My response to his posting in this thread
>was written in the belief that he would see it normally.
>Sorry for any confusion.

You two crazy kids...

You really need to just get a room together and hash this all out.

When you do, everybody can be happy once again.

-- 
You are again heaping damnation upon your own head by your statements.

    - Rick C Hodgin -

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

#142018

On Monday, March 18, 2019 at 1:03:13 AM UTC-4, Kenny McCormack wrote:
> You are again heaping damnation upon your own head by your statements.
> 
>     - Rick C Hodgin -

Context:

    https://groups.google.com/d/msg/comp.lang.c++/oeH4xHZ4JOg/Z-1tvbJAAAAJ

-- 
Rick C. Hodgin

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

#142028

gazelle@shell.xmission.com (Kenny McCormack) writes:

> In article <8636nkre0s.fsf@mailhub.linuxsc.com>,
> Tim Rentsch  <tr.17687@z991.linuxsc.com> wrote:
>
>> Keith Thompson <kst-u@mib.org> writes:
>> [...]
>
> You really need to just get a room together and hash this all out.

That advice applies to you more than it does to me.

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

#142038

In article <86tvg0patc.fsf@mailhub.linuxsc.com>,
Tim Rentsch  <tr.17687@z991.linuxsc.com> wrote:
>gazelle@shell.xmission.com (Kenny McCormack) writes:
>
>> In article <8636nkre0s.fsf@mailhub.linuxsc.com>,
>> Tim Rentsch  <tr.17687@z991.linuxsc.com> wrote:
>>
>>> Keith Thompson <kst-u@mib.org> writes:
>>> [...]
>>
>> You really need to just get a room together and hash this all out.
>
>That advice applies to you more than it does to me.

Nice 8th grade insult there.

"I know you are, but what am I???"

It's actually funny how often you get this 8th grade level stuff in
supposedly adult-centered online forums.  Way to keep up the trend!

-- 
Trump has normalized hate.

The media has normalized Trump.

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

#142016

Richard Damon <Richard@Damon-Family.org> writes:

> On 3/17/19 8:41 PM, Tim Rentsch wrote:
>
>> Keith Thompson <kst-u@mib.org> writes:
>>
>>> In Richard's example, if the scopes of the two `x`s extended beyond the
>>> if-else statement, it would be difficult to define the semantics or,
>>> more likely, the second declaration would be illegal for the same
>>> reason.  If the scopes were defined as they are in C++, they would be
>>> non-overlapping and unambiguous (and not useful, since nothing could
>>> refer to either `x`).
>>
>> I think you (and also Richard Damon) are forgetting 6.8.4 p3
>> (already present in C99, though not in C90):
>>
>>     A selection statement is a block whose scope is a strict
>>     subset of the scope of its enclosing block.  Each associated
>>     substatement is also a block whose scope is a strict subset
>>     of the scope of the selection statement.
>
> I will admit that I hadn't followed the standards into that detail an
> missed that they changed to make the statements implicit scopes.

As I recall it wasn't something I discovered on my own.  In fact,
if memory serves, it was from a posting by Keith Thompson that I
first found out about it.

> With that changed, I am not sure if there is any particular difficulty
> in changing the grammar so that declarations are fully a statement, and
> thus could have a label in front of it.

I think it's pretty straightforward.  Simply add 'declaration' as
an alternative under 'statement'.  (I think it's better to leave
plain 'declaration' alone, as otherwise top-level declarations
could syntactically have meaningless labels on them.)  Or, another
approach, for the non-terminal 'block-item', change the alternative
'declaration' to 'labeled-declaration', and add a rule for that:

    labeled-declaration:
        identifier  :  labeled-declaration
        case  constant-expression  :  labeled-declaration
        default  :  labeled-declaration
        declaration

This scheme would allow labels on declarations that are at the
level of statements in a compound statement, but would not allow
declarations (whether labeled or not) as the controlled statement
of an 'if', etc.  Personally I like the second scheme better, but
I don't think either one is worth the effort - two or three
milligrams of syntactic sugar whose primary benefit is to make
writing goto's more convenient.  Better to just leave things as
they are.

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

#142007

On 3/17/19 7:16 PM, Keith Thompson wrote:
> Richard Damon <Richard@Damon-Family.org> writes:
> [...]
>> 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
> [...]
> 
> C++ allows this; a declaration (if it appears inside a function
> defintion) is a kind of statement.  The scope of x is limited to the
> declaration-statement, so the above is equivalent to:
> 
>     if (flag) { int x; }
>     else      { float x; }
> 
> which is valid in C.
> 

Yes, C++ basically defines a number of implicit block scopes which C
doesn't, which I suppose would be the other way around the issue.

If fact, the if statement introduces 3 implicit scopes so

if(bool flag = f()) int x;
else                float x;

becomes:

{ if(bool flag = f()) { int x; }
  else                { float x; }
}

I suppose C++ needs to be more complicated about where to allow
declarations as basically ALL declarations (except perhaps for primative
types) generate executable code, as the constructor for the object is
called, so

  FooType foo;
  foo = foovalue;

is significantly different than

  FooType foo - foovalue;

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

#141999

On Sunday, March 17, 2019 at 9:45:38 AM UTC-5, 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?
> 

I haven't done this with goto, but I have done it plenty with cases in 
switch statements. More recently, I tend to write a subfunction if the
code for a case needs its own variables. But if it were appropriate to
inline such a function (ends up only called once and needs to compile
on a primitive compiler where manual inlining is useful), then it seems
perfectly appropriate to use an empty statement so the label can be
used on it.

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

#142012

On 3/17/2019 10:45 PM, Kenny McCormack wrote:
> 
> ...
> 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.

A goto does not need to save stack, unlike calling a function. Faster, 
maybe.


-- 
   @~@   Remain silent! Drink, Blink, Stretch! Live long and prosper!!
  / v \  Simplicity is Beauty!
/( _ )\ May the Force and farces be with you!
   ^ ^   (x86_64 Ubuntu 9.10)  Linux 2.6.39.3
¤£­É¶U! ¤£¶BÄF! ¤£½ä¿ú! ¤£´©¥æ! ¤£¥´¥æ! ¤£¥´§T! ¤£¦Û±þ! ¤£¨D¯«! 
½Ð¦Ò¼{ºî´© (CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa

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

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

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

csiph-web