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

#142268

On Friday, March 22, 2019 at 1:59:12 PM UTC-7, Rick C. Hodgin wrote:
> On Friday, March 22, 2019 at 1:16:08 PM UTC-4, Chad wrote:
> > On Thursday, March 21, 2019 at 2:30:17 PM UTC-7, Rick C. Hodgin wrote:
> > > CAlive is so named to give C new life (among other things).
> > > If I ever complete it, everyone will have this option.
> > 
> > Do you have the tokenizer completed?
> 
> I don't do drugs.  I'm strait-lace, sir.
> 
> > If so, do you have the production rules for the language
> > grammar written down?
> 
> I hated grammar in school.  My worst subject.  I did like the
> predicate nominative though.  A stand out there in a sea of
> otherwise doldrum.  Conjunctions weren't bad either, but mostly
> because I liked the song.  "Con-junc-tion junc-tion.  What's
> your function?  Pickin' up nouns and phrases and clauses."  Oh
> some happy boyhood memories.
> 
> > Because if you can't do that, well CAlive .. it will never happen.
> 
> You mean ... wait ... I have to know grammar to complete CAlive?
> Aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaargh!
> Noooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo!
> Khaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaan!
> 
https://en.wikipedia.org/wiki/Automata_theory

Or if that is too much, do you want me to send you my used book on Automata Theory from a two term CS class that I was required to take back before you had to use Viagra?

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

#142269

On Friday, March 22, 2019 at 6:10:28 PM UTC-4, Chad wrote:
> [snip]

From the movie Real Genius:  "Thank you, Mitch."

When you get that statement of faith ... you're welcome onto the
project.

There's a purposeful reason why I seek to do this project for the
Lord first, and other reasons second.  It's so I give Him my best,
weak as that might be.  I'm not guided by other draws or pulls.
I'm digging within the resources He gave me, and pulling out the
absolute best I have to hand to Him.

I do this purposefully because of who He is, and what He's done
for me, all of your in-response Viagra-type comments notwithstand-
inating.

#SeekTheTruth, Chad.  It's not for religion.  It's not for the 10%
tithe each week.  It's for the Living God, my friend.  It's for
the Living God.

-- 
Rick C. Hodgin

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

#142225

On 21/03/2019 21:19, Jorgen Grahn wrote:
> On Thu, 2019-03-21, Rick C. Hodgin wrote:
> ...
>> I've observed an entire philosophy in many people of the C language
>> that seems to be 100% backward from the way things should be.  I
>> don't know what the cause of that is, and I don't remember seeing
>> it any place else except in some aspects of UNIX/Linux's design.
> 
> From my point of view it's you (and Bart, and a handful of other
> posters) who have it backwards.  Being (it seems to me) more
> interested in new language features than in writing useful programs
> using the existing features.
> 
> If it's any comfort, there seem to be other communities where things
> are how you think they should be: fast-moving languages like Python3,
> Groovy and ... probably many others; I don't keep track.
> 
> (Last thing I heard, PHP had been reworked, and is now considered cool
> again.)
> 

I think you have made an important point here.  There is a need for
languages that change and adapt, and provide newer features.  There is
also a need for languages that are stable, where you can rely on
backwards compatibility, and where you can take old code and have it
work on new tools (baring bugs, of course - nothing in software is perfect).

C is a language where backwards compatibility is of prime concern.  That
is a major strength of the language - but it is also a hinder going
forward, and it is part of the reason why C is /not/ now a good choice
for a lot of programming tasks where it made sense 30 years ago.

Python is a language where backwards compatibility is much less of a
concern, and where it is not guaranteed at all between major versions.
This lets Python move forward and gain new features at a far higher rate
than C.  It also means that older Python code often won't work on newer
Python runtimes, and you can have a lot of challenges mixing old and new
code.

They are different languages, for different purposes, with different
balances.  We need both.

C++, as usual, tries to find a middle ground and keep everyone happy -
having backwards compatibility /and/ steadily more new features.  It
does rather well at it, but this has a cost in complexity and sometimes
rather ugly syntax.  Again, it's a balance - no language can do
everything and suit everyone.

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

#142245

On Friday, March 22, 2019 at 1:22:29 AM UTC-7, David Brown wrote:
> On 21/03/2019 21:19, Jorgen Grahn wrote:
> > On Thu, 2019-03-21, Rick C. Hodgin wrote:
> > ...
> >> I've observed an entire philosophy in many people of the C language
> >> that seems to be 100% backward from the way things should be.  I
> >> don't know what the cause of that is, and I don't remember seeing
> >> it any place else except in some aspects of UNIX/Linux's design.
> > 
> > From my point of view it's you (and Bart, and a handful of other
> > posters) who have it backwards.  Being (it seems to me) more
> > interested in new language features than in writing useful programs
> > using the existing features.
> > 
> > If it's any comfort, there seem to be other communities where things
> > are how you think they should be: fast-moving languages like Python3,
> > Groovy and ... probably many others; I don't keep track.
> > 
> > (Last thing I heard, PHP had been reworked, and is now considered cool
> > again.)
> > 
> 
> I think you have made an important point here.  There is a need for
> languages that change and adapt, and provide newer features.  There is
> also a need for languages that are stable, where you can rely on
> backwards compatibility, and where you can take old code and have it
> work on new tools (baring bugs, of course - nothing in software is perfect).
> 
> C is a language where backwards compatibility is of prime concern.  That
> is a major strength of the language - but it is also a hinder going
> forward, and it is part of the reason why C is /not/ now a good choice
> for a lot of programming tasks where it made sense 30 years ago.
> 
> Python is a language where backwards compatibility is much less of a
> concern, and where it is not guaranteed at all between major versions.
> This lets Python move forward and gain new features at a far higher rate
> than C.  It also means that older Python code often won't work on newer
> Python runtimes, and you can have a lot of challenges mixing old and new
> code.
> 

I can't speak for python, but some languages can get around this by using combination of Dynamic Binding and Polymorphism. So if there is a new version of the code, the existing code looks up a specific implementation based on the concrete type of the class.

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

#142248

On 3/21/2019 6:04 PM, Rick C. Hodgin wrote:
> On Thursday, March 21, 2019 at 12:48:54 PM UTC-4, Manfred wrote:
>> On 3/17/2019 11:55 PM, 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.
>>
>> As Tim Rentsch pointed out, this is not backwards compatible, so too
>> much impractical for a language like C, especially considering that the
>> alternative of adding an extra ';' is not too difficult (once you know it).
> 
> I do not understand this limitation people impose upon C.
> 
> There is no problem maintaining backward compatibility when adding
> new features ... if those features are not enabled by default, but
> are enabled via some switch.
> 
> You can add new features to a language which must be enabled to be
> used.  Once enabled, only then it would break backward compatibility.

The C standard does not interact with compiler switches. This is clearly 
an intentional choice of the committee that wants to keep the language 
specification to the code text only - a choice that makes sense to me.

The standard allows for some optional features, enabled by preprocessor 
definitions. This implies that functionality provided by the standard 
library can be made optional, but features of the language itself cannot.
So, for this case, the semantics of a C label, this would not work.

> 
> But to not add any new features (and not particularly this one, but
> more of an "in general" concept) because they may break backward
> compatibility ... I think that's a wrong philosophy, a wrong way of
> thinking, and a wrong decision.
> 
> New features SHOULD be added.  And if there's legitimate concern
> about it breaking non-trivial amounts of code, then it should be
> added as a feature which must be enabled.  But, new features should
> be made available to developers in a language over time.
> 
>> Otherwise, I think this would have been a smart solution. Probably
>> better than making declarations into statements, which would require
>> much more work on the general scoping rules.
>>
>> 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.
> 
> I've observed an entire philosophy in many people of the C language
> that seems to be 100% backward from the way things should be.  I
> don't know what the cause of that is, and I don't remember seeing
> it any place else except in some aspects of UNIX/Linux's design.

Due to the huge amount of C code running out there, and the kind of 
environment C has been adopted for - systems programming, industrial 
applications, safety critical controls etc. - C has become a very 
conservative language.
I think this conservative attitude is simply motivated by the language 
users to /require/ C to be primarily stable and backwards compatible.
This is a very practical need, not much a matter of philosophy.
In other words, any breaking change in the language would be extremely 
expensive, both because of the amount of existing and running code out 
there, and because of the sensitive nature of a lot of such code - 
imagine the amount of code review, re-testing and validation needed for 
a flight control component implemented in C, in case of a change in the 
language; if this had to be re-executed only because of some breaking 
change that is so 'cool', the committee would probably receive a few 
heated e-mails - and rightfully.

> 
> It's like this whole backward ecosystem rose out of K&R and Stallman
> and other early adopters which pushed to make it all public, and it's
> persisted that way from their initial seeds.
> 
> The idea of creating a language which operates on minimums ... it
> does make sense in the 70s, 80s, and probably even 90s, but not in
> the 00s, and certainly not in the 10s or 20s.
> 
> Those seeds need to be supplanted with new long-term seeds which do
> make real sense.
> 
> The existing C compilers and code which exist can continue to be
> compiled, and new features can be added, and changes can be made,
> without breaking anything historically.
> 
> The biggest ones I'd like to see is the removal of the requirement
> of having forward declarations.  Our computers today are fast enough
> we do not need that extra workload for the developer any longer.
> 
> Another one for C would be the introduction of the basic class.  It
> is a beautiful way to write code, though it could use some changes
> in syntax to make it more beautiful (especially for accessor methods).
> 
> Such simple augments to save man-weeks of work per developer per
> year if properly employed with inheritance and the like.

There are plenty of other languages that are much more dynamic. Luckily 
today's programmers have lots of alternatives to choose from.

> 
> If only...
> 

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

#142250

On Friday, March 22, 2019 at 1:16:01 PM UTC-4, Manfred wrote:
> On 3/21/2019 6:04 PM, Rick C. Hodgin wrote:
> > On Thursday, March 21, 2019 at 12:48:54 PM UTC-4, Manfred wrote:
> >> On 3/17/2019 11:55 PM, 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.
> >>
> >> As Tim Rentsch pointed out, this is not backwards compatible, so too
> >> much impractical for a language like C, especially considering that the
> >> alternative of adding an extra ';' is not too difficult (once you know it).
> > 
> > I do not understand this limitation people impose upon C.
> > 
> > There is no problem maintaining backward compatibility when adding
> > new features ... if those features are not enabled by default, but
> > are enabled via some switch.
> > 
> > You can add new features to a language which must be enabled to be
> > used.  Once enabled, only then it would break backward compatibility.
> 
> The C standard does not interact with compiler switches...
> 
> The standard allows for some optional features, enabled by preprocessor 
> definitions...

That's a switch.

As for your other comments:  that's why I created CAlive.  I can't
move C, but I can move C into CAlive and its changes.

-- 
Rick C. Hodgin

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

#142252

Manfred <invalid@add.invalid> writes:
[...]
> The standard allows for some optional features, enabled by preprocessor 
> definitions. This implies that functionality provided by the standard 
> library can be made optional, but features of the language itself cannot.
> So, for this case, the semantics of a C label, this would not work.
[...]

No, language features can be and are made optional.  In C11, complex
numbers, atomic types, complex types, and VLAs, among other things,
are optional, and each has a corresponding predefined macro that
indicates whether the implementation supports it.  See C11/N1570
6.10.8.3.

-- 
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]

#142293

On 3/22/2019 7:31 PM, Keith Thompson wrote:
> Manfred <invalid@add.invalid> writes:
> [...]
>> The standard allows for some optional features, enabled by preprocessor
>> definitions. This implies that functionality provided by the standard
>> library can be made optional, but features of the language itself cannot.
>> So, for this case, the semantics of a C label, this would not work.
> [...]
> 
> No, language features can be and are made optional.  In C11, complex
> numbers, atomic types, complex types, and VLAs, among other things,
> are optional, and each has a corresponding predefined macro that
> indicates whether the implementation supports it.  See C11/N1570
> 6.10.8.3.
> 
That's not what I meant: the macros you refer to are defined by the 
implementation to indicate whether the implementation supports such 
language features. They are not meant for the programmer to #define or 
#undef to switch such features on/off.

Instead, when I wrote the post I had in mind macros like 
_USE_MATH_DEFINES that enables #define's of stuff like M_PI, but later I 
realized that this is not part of the ISO standard, so I was probably 
wrong with the part of the standard allowing for such customization via 
preprocessor definitions (selectable by the programmer, not the 
implementation).

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

#142313

Manfred <noname@add.invalid> writes:

> On 3/22/2019 7:31 PM, Keith Thompson wrote:
>
>> Manfred <invalid@add.invalid> writes:
>> [...]
>>
>>> The standard allows for some optional features, enabled by preprocessor
>>> definitions.  This implies that functionality provided by the standard
>>> library can be made optional, but features of the language itself cannot.
>>> So, for this case, the semantics of a C label, this would not work.
>>
>> [...]
>>
>> No, language features can be and are made optional.  In C11, complex
>> numbers, atomic types, complex types, and VLAs, among other things,
>> are optional, and each has a corresponding predefined macro that
>> indicates whether the implementation supports it.  See C11/N1570
>> 6.10.8.3.
>
> That's not what I meant:  the macros you refer to are defined by the
> implementation to indicate whether the implementation supports such
> language features.  They are not meant for the programmer to #define or
> #undef to switch such features on/off.
>
> Instead, when I wrote the post I had in mind macros like
> _USE_MATH_DEFINES that enables #define's of stuff like M_PI, but later
> I realized that this is not part of the ISO standard, so I was
> probably wrong with the part of the standard allowing for such
> customization via preprocessor definitions (selectable by the
> programmer, not the implementation).

ISO C does have a standard mechanism whereby programs can direct
an implementation to alter the source language in some way, and
which could be used to cause preprocessor changes like #define'ing
M_PI, or other things.  The mechanism is #pragma.  In current C
there are, IIRC, only three standardized #pragma's (those being
CX_LIMITED_RANGE, FENV_ACCESS, and FP_CONTRACT, all under #pragma
STDC), but others could be added to control code behavior
semantics, what symbols are defined by which standard header
files, or even what source language constructs are allowed.  So an
option to allow labels on declarations could be provided, as for
example

    #pragma STDC DECLARATIONS_MAY_HAVE_LABELS ON

which would fit easily into the existing ISO standard.  Of course,
implementing such things might be a nightmare, but there is an
"ISO C normal" way of specifying them.

(Please note that I am not suggesting that this /should/ be done,
only that it /could/ be done.)

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

#142316

On 3/23/19 4:36 PM, Tim Rentsch wrote:
> ISO C does have a standard mechanism whereby programs can direct
> an implementation to alter the source language in some way, and
> which could be used to cause preprocessor changes like #define'ing
> M_PI, or other things.  The mechanism is #pragma.  In current C
> there are, IIRC, only three standardized #pragma's (those being
> CX_LIMITED_RANGE, FENV_ACCESS, and FP_CONTRACT, all under #pragma
> STDC), but others could be added to control code behavior
> semantics, what symbols are defined by which standard header
> files, or even what source language constructs are allowed.  So an
> option to allow labels on declarations could be provided, as for
> example
> 
>     #pragma STDC DECLARATIONS_MAY_HAVE_LABELS ON
> 
> which would fit easily into the existing ISO standard.  Of course,
> implementing such things might be a nightmare, but there is an
> "ISO C normal" way of specifying them.
> 
> (Please note that I am not suggesting that this /should/ be done,
> only that it /could/ be done.)

In my view, that isn't something that would need a pragma, since once
the effort was made to produce a grammar that allowed labels on
declarations, I can see no reason that one would want the disabled, thus
no need for a pragma.

If the solution to implementing this was that labels became statements
of their own, so things like

if(x) label: x = 0;

changed meaning (as the label now was the conditional statement, and x=0
now became unconditionally executed, THAT would need a pragma, but I
think the consequences of that are bad enough that it wouldn't be the
way to implement it.

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

#142414

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

> On 3/23/19 4:36 PM, Tim Rentsch wrote:
>
>> ISO C does have a standard mechanism whereby programs can direct
>> an implementation to alter the source language in some way, and
>> which could be used to cause preprocessor changes like #define'ing
>> M_PI, or other things.  The mechanism is #pragma.  In current C
>> there are, IIRC, only three standardized #pragma's (those being
>> CX_LIMITED_RANGE, FENV_ACCESS, and FP_CONTRACT, all under #pragma
>> STDC), but others could be added to control code behavior
>> semantics, what symbols are defined by which standard header
>> files, or even what source language constructs are allowed.  So an
>> option to allow labels on declarations could be provided, as for
>> example
>>
>>     #pragma STDC DECLARATIONS_MAY_HAVE_LABELS ON
>>
>> which would fit easily into the existing ISO standard.  Of course,
>> implementing such things might be a nightmare, but there is an
>> "ISO C normal" way of specifying them.
>>
>> (Please note that I am not suggesting that this /should/ be done,
>> only that it /could/ be done.)
>
> In my view, that isn't something that would need a pragma, since once
> the effort was made to produce a grammar that allowed labels on
> declarations, I can see no reason that one would want the disabled, thus
> no need for a pragma.

There are at least two reasons someone might prefer the OFF
choice in the #pragma.  One is to retain compatibility with
earlier versions of the Standard, to ensure other compiler
environments will not have a problem.  Two is to prevent
suspect uses that might otherwise arise by accident or
oversight.  For example

    switch(...){
        ...

        case whatever:
            char *p = ...;
            ...

        ...
    }

Normally we would expect braces around code for the 'whatever'
branch of the switch(), so this looks like it is probably an
error.  It would be nice if the compiler would flag it for
us, and choosing OFF in the #pragma would do that.

> If the solution to implementing this was that labels became statements
> of their own, so things like
>
> if(x) label:  x = 0;
>
> changed meaning (as the label now was the conditional statement, and x=0
> now became unconditionally executed, THAT would need a pragma, but I
> think the consequences of that are bad enough that it wouldn't be the
> way to implement it.

Right.  IMO no sensible person would disagree with that.

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

#142261

On Friday, March 22, 2019 at 1:16:01 PM UTC-4, Manfred wrote:
...
> The standard allows for some optional features, enabled by preprocessor 
> definitions.

I presume you're referring to the "Conditional feature macros" defined
in 6.10.8.3? Those macros are pre#defined by the implementation to
report whether the optionally-supported feature is in fact supported.
#defining them yourself doesn't enable the corresponding feature.

> ... This implies that functionality provided by the standard 
> library can be made optional, but features of the language itself cannot.

The conditional feature are mostly features of the language itself,
though in many cases they also involve the standard library.

_ _STDC_ANALYZABLE_ _ affects nearly every operation with undefined
behavior.
While _ _STDC_IEC_559_ _ and _ _STDC_IEC_559_COMPLEX_ _ have many
effects on <math.h> and <complex.h> functions, they also affects
ordinary floating point operations.
_ _STDC_NO_ATOMICS_ _ affects the _Atomic keyword.
_ _STDC_NO_ATOMICS_ _ doesn't just affect the functions in <complex.h>
it also affects ordinary complex floating point operations.
_ _STDC_NO_VLA_ _ has no affect on the library - it only affects
declarations of VLAs.

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

#142267

On Friday, March 22, 2019 at 3:59:23 PM UTC-4, James Kuyper wrote:
> I presume you're referring to the "Conditional feature macros" defined
> in 6.10.8.3? Those macros are pre#defined by the implementation to
> report whether the optionally-supported feature is in fact supported.
> #defining them yourself doesn't enable the corresponding feature.
> 
> > ... This implies that functionality provided by the standard 
> > library can be made optional, but features of the language itself cannot.
> 
> The conditional feature are mostly features of the language itself,
> though in many cases they also involve the standard library.
> 
> _ _STDC_ANALYZABLE_ _
> _ _STDC_IEC_559_ _
> _ _STDC_IEC_559_COMPLEX_ _
> _ _STDC_NO_ATOMICS_ _
> _ _STDC_NO_ATOMICS_ _
> _ _STDC_NO_VLA_ _

I like the way Visual Studio allows compiler and languages optiosn
to be enabled via a #pragma.

    #pragma comment(lib, "path/to/mylib.lib")

Things like that.  It documents then in source code the requirements
so you don't have to have a separate project or know the specific
command-line options to introduce.  The idea to simply have a single
simple command like "compile myapp.c" and it will compile if you set
things up properly internally.

It's how it should be in my opinion.  That way you can create a std
set of abilities you use for your apps, and then one #include line
and your app is ready to go like normal, not just with other #include
references, but also with compiler settings and the like.

CAlive actually allows for some body content of the source file to
be the compile script, which runs as a C-like language at compile-
time (runs as CAlive code, which supports most C things).

In any event ... who cares, right? :-)

-- 
Rick C. Hodgin

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

#142273

On 22/03/2019 22:03, Rick C. Hodgin wrote:
> On Friday, March 22, 2019 at 3:59:23 PM UTC-4, James Kuyper wrote:
>> I presume you're referring to the "Conditional feature macros" defined
>> in 6.10.8.3? Those macros are pre#defined by the implementation to
>> report whether the optionally-supported feature is in fact supported.
>> #defining them yourself doesn't enable the corresponding feature.
>>
>>> ... This implies that functionality provided by the standard
>>> library can be made optional, but features of the language itself cannot.
>>
>> The conditional feature are mostly features of the language itself,
>> though in many cases they also involve the standard library.
>>
>> _ _STDC_ANALYZABLE_ _
>> _ _STDC_IEC_559_ _
>> _ _STDC_IEC_559_COMPLEX_ _
>> _ _STDC_NO_ATOMICS_ _
>> _ _STDC_NO_ATOMICS_ _
>> _ _STDC_NO_VLA_ _
> 
> I like the way Visual Studio allows compiler and languages optiosn
> to be enabled via a #pragma.
> 
>      #pragma comment(lib, "path/to/mylib.lib")
> 
> Things like that.  It documents then in source code the requirements
> so you don't have to have a separate project or know the specific
> command-line options to introduce.  The idea to simply have a single
> simple command like "compile myapp.c" and it will compile if you set
> things up properly internally.
> 

That is a rather different thing - or at least a different viewpoint. 
The optional features in the standards allow compilers to be made 
compliant while skipping features that might be impractical on the 
platform (such as complex numbers on a compiler for an 8-bit 
microcontroller - or the analysability stuff that is, IMHO, impractical 
everywhere).  These predefined macros let you test what the compiler 
supports, and adapt your code accordingly (or exit with an #error if you 
needed that feature).

Compiler options - or pragmas - let you control the compiler, rather 
than letting the compiler control your code.  It is the other way round.

But I agree that such pragmas can be a very useful feature, and can be 
the right place to put some kind of options.  For example, when using 
third-party code in a project, I might add a line:

	#pragma GCC optimize("-fno-strict-aliasing")

because I know that code breaks C rules about accessing data via 
incompatible pointers.  This means the code is now safe for gcc, 
regardless of the optimisation options that might be picked in the 
Makefile or other build system.  Similarly, I might have pragmas to turn 
off warnings that I use on my own code, but which lead to false 
positives in code written in a different style.

"#pragma comment" is perhaps the worst conceivable choice of pragma name 
for something that actually affects how the code is interpreted or 
compiled, but I assume MSVC has better named pragmas available.

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

#142348

On Sat, 23 Mar 2019 12:44:17 +0100, David Brown
<david.brown@hesbynett.no> wrote:

>On 22/03/2019 22:03, Rick C. Hodgin wrote:
>> On Friday, March 22, 2019 at 3:59:23 PM UTC-4, James Kuyper wrote:
>>> I presume you're referring to the "Conditional feature macros" defined
>>> in 6.10.8.3? Those macros are pre#defined by the implementation to
>>> report whether the optionally-supported feature is in fact supported.
>>> #defining them yourself doesn't enable the corresponding feature.
>>>
>>>> ... This implies that functionality provided by the standard
>>>> library can be made optional, but features of the language itself cannot.
>>>
>>> The conditional feature are mostly features of the language itself,
>>> though in many cases they also involve the standard library.
>>>
>>> _ _STDC_ANALYZABLE_ _
>>> _ _STDC_IEC_559_ _
>>> _ _STDC_IEC_559_COMPLEX_ _
>>> _ _STDC_NO_ATOMICS_ _
>>> _ _STDC_NO_ATOMICS_ _
>>> _ _STDC_NO_VLA_ _
>> 
>> I like the way Visual Studio allows compiler and languages optiosn
>> to be enabled via a #pragma.
>> 
>>      #pragma comment(lib, "path/to/mylib.lib")
>> 
>> Things like that.  It documents then in source code the requirements
>> so you don't have to have a separate project or know the specific
>> command-line options to introduce.  The idea to simply have a single
>> simple command like "compile myapp.c" and it will compile if you set
>> things up properly internally.
>> 
>
>That is a rather different thing - or at least a different viewpoint. 
>The optional features in the standards allow compilers to be made 
>compliant while skipping features that might be impractical on the 
>platform (such as complex numbers on a compiler for an 8-bit 
>microcontroller - or the analysability stuff that is, IMHO, impractical 
>everywhere).  These predefined macros let you test what the compiler 
>supports, and adapt your code accordingly (or exit with an #error if you 
>needed that feature).
>
>Compiler options - or pragmas - let you control the compiler, rather 
>than letting the compiler control your code.  It is the other way round.
>
>But I agree that such pragmas can be a very useful feature, and can be 
>the right place to put some kind of options.  For example, when using 
>third-party code in a project, I might add a line:
>
>	#pragma GCC optimize("-fno-strict-aliasing")
>
>because I know that code breaks C rules about accessing data via 
>incompatible pointers.  This means the code is now safe for gcc, 
>regardless of the optimisation options that might be picked in the 
>Makefile or other build system.  Similarly, I might have pragmas to turn 
>off warnings that I use on my own code, but which lead to false 
>positives in code written in a different style.
>
>"#pragma comment" is perhaps the worst conceivable choice of pragma name 
>for something that actually affects how the code is interpreted or 
>compiled, but I assume MSVC has better named pragmas available.


It's an unfortunate name, but it's a direct reference to comment
sections and entries in PE/COFF files that exist to pass information
in object files and executable to other programs.

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

#142294

On 3/22/2019 8:59 PM, James Kuyper wrote:
> On Friday, March 22, 2019 at 1:16:01 PM UTC-4, Manfred wrote:
> ...
>> The standard allows for some optional features, enabled by preprocessor
>> definitions.
> 
> I presume you're referring to the "Conditional feature macros" defined
> in 6.10.8.3? Those macros are pre#defined by the implementation to
> report whether the optionally-supported feature is in fact supported.
> #defining them yourself doesn't enable the corresponding feature.

No, that's not what I was referring to. I was referring to (possible) 
macro definitions #define-able by the programmer to switch features on 
/off, and after further evaluation I may have been wrong that the ISO 
standard allows for any of these. I had in mind something like 
_USE_MATH_DEFINES that enables M_PI and friends on glibc, but this is 
not part of ISO C.

> 
>> ... This implies that functionality provided by the standard
>> library can be made optional, but features of the language itself cannot.
> 
> The conditional feature are mostly features of the language itself,
> though in many cases they also involve the standard library.
As said, these are not switches selectable by the programmer (as I 
understand Rick was suggesting)

> 
> _ _STDC_ANALYZABLE_ _ affects nearly every operation with undefined
> behavior.
> While _ _STDC_IEC_559_ _ and _ _STDC_IEC_559_COMPLEX_ _ have many
> effects on <math.h> and <complex.h> functions, they also affects
> ordinary floating point operations.
> _ _STDC_NO_ATOMICS_ _ affects the _Atomic keyword.
> _ _STDC_NO_ATOMICS_ _ doesn't just affect the functions in <complex.h>
> it also affects ordinary complex floating point operations.
> _ _STDC_NO_VLA_ _ has no affect on the library - it only affects
> declarations of VLAs.
> 

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

#142421

On Saturday, March 23, 2019 at 12:48:47 PM UTC-4, Manfred wrote:
> On 3/22/2019 8:59 PM, James Kuyper wrote:
> > On Friday, March 22, 2019 at 1:16:01 PM UTC-4, Manfred wrote:
> > ...
> >> The standard allows for some optional features, enabled by preprocessor
> >> definitions.
> > 
> > I presume you're referring to the "Conditional feature macros" defined
> > in 6.10.8.3? Those macros are pre#defined by the implementation to
> > report whether the optionally-supported feature is in fact supported.
> > #defining them yourself doesn't enable the corresponding feature.
> 
> No, that's not what I was referring to. I was referring to (possible) 
> macro definitions #define-able by the programmer to switch features on 
> /off, and after further evaluation I may have been wrong that the ISO 
> standard allows for any of these.

I was trying to guess whether you were misunderstanding how the standard
macros worked, or incorrectly believed that the macros you were talking
about were standard-defined. I guessed wrong, but I was right about
those being the only two options.

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

#142218

On Thu, 21 Mar 2019 17:48:46 +0100, Manfred <noname@add.invalid>
wrote:

>On 3/17/2019 11:55 PM, Bart wrote:
>> 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.
>> 
>
>As Tim Rentsch pointed out, this is not backwards compatible, so too 
>much impractical for a language like C, especially considering that the 
>alternative of adding an extra ';' is not too difficult (once you know it).
>Otherwise, I think this would have been a smart solution. Probably 
>better than making declarations into statements, which would require 
>much more work on the general scoping rules.
>
>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.

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

#142246

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.

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

#142251

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

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

-- 
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]

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

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

csiph-web