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

Groups > comp.std.c > #5990 > unrolled thread

Addition of nocode keyword

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

Contents

  Addition of nocode keyword "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-10-25 05:26 -0700
    Re: Addition of nocode keyword Philipp Klaus Krause <pkk@spth.de> - 2019-10-25 15:53 +0200
      Re: Addition of nocode keyword "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-10-25 07:26 -0700
        Re: Addition of nocode keyword Philipp Klaus Krause <pkk@spth.de> - 2020-08-04 11:00 +0200
    Re: Addition of nocode keyword "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-10-25 11:04 -0700
    Re: Addition of nocode keyword Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-25 23:42 +0100
      Re: Addition of nocode keyword "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-10-25 22:20 -0400
        Re: Addition of nocode keyword Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-26 22:52 +0100
          Re: Addition of nocode keyword Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-26 23:27 +0100
          Re: Addition of nocode keyword "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-10-26 17:19 -0700
    Re: Addition of nocode keyword Richard Damon <Richard@Damon-Family.org> - 2019-10-25 22:10 -0300
      Re: Addition of nocode keyword "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-10-25 19:02 -0700
        Re: Addition of nocode keyword Richard Damon <Richard@Damon-Family.org> - 2019-10-28 23:45 -0400
          Re: Addition of nocode keyword "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-10-29 08:15 -0400
            Re: Addition of nocode keyword "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-10-29 08:42 -0400
            Re: Addition of nocode keyword Richard Damon <Richard@Damon-Family.org> - 2019-10-29 22:37 -0400
              Re: Addition of nocode keyword "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-10-30 05:10 -0700
      Re: Addition of nocode keyword Philipp Klaus Krause <pkk@spth.de> - 2019-10-26 18:45 +0200
    Re: Addition of nocode keyword Jakob Bohm <jb-usenet@wisemo.com.invalid> - 2019-10-28 10:42 +0100
      Re: Addition of nocode keyword "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-10-28 18:13 -0700
        Re: Addition of nocode keyword David Spencer <spencer@panix.com> - 2019-10-29 02:55 +0000
          Re: Addition of nocode keyword "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-10-29 07:58 -0400
            Re: Addition of nocode keyword David Spencer <spencer@panix.com> - 2019-10-29 20:21 +0000
              Re: Addition of nocode keyword "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-10-29 13:31 -0700
                Re: Addition of nocode keyword jameskuyper@alumni.caltech.edu - 2019-10-29 14:47 -0700
                  Re: Addition of nocode keyword "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-10-29 19:36 -0400
                    Re: Addition of nocode keyword Richard Damon <Richard@Damon-Family.org> - 2019-10-29 22:13 -0400
                      Re: Addition of nocode keyword "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-10-30 05:03 -0700
                    Re: Addition of nocode keyword David Brown <david.brown@hesbynett.no> - 2019-10-30 09:48 +0100
                      Re: Addition of nocode keyword "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-10-30 05:13 -0700
                        Re: Addition of nocode keyword Keith Thompson <kst-u@mib.org> - 2019-10-30 08:40 -0700
                          Re: Addition of nocode keyword "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-10-30 09:44 -0700
                            Re: Addition of nocode keyword David Brown <david.brown@hesbynett.no> - 2019-10-30 18:30 +0100
                    Re: Addition of nocode keyword jameskuyper@alumni.caltech.edu - 2019-10-30 08:12 -0700
                      Re: Addition of nocode keyword Nick Bowler <nbowler@draconx.ca> - 2019-10-30 16:47 +0000
                        Re: Addition of nocode keyword James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-10-30 13:30 -0400
                        Re: Addition of nocode keyword David Brown <david.brown@hesbynett.no> - 2019-10-30 18:37 +0100
                          Re: Addition of nocode keyword Nick Bowler <nbowler@draconx.ca> - 2019-10-30 18:34 +0000
                          Re: Addition of nocode keyword Keith Thompson <kst-u@mib.org> - 2019-10-31 10:14 -0700
                      Re: Addition of nocode keyword "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-10-30 21:29 -0400
                        Re: Addition of nocode keyword jameskuyper@alumni.caltech.edu - 2019-10-31 08:37 -0700
                          Re: Addition of nocode keyword "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-10-31 09:38 -0700
                            Re: Addition of nocode keyword David Brown <david.brown@hesbynett.no> - 2019-10-31 19:50 +0100
                        Re: Addition of nocode keyword Philipp Klaus Krause <pkk@spth.de> - 2020-08-04 11:18 +0200
                      Re: Addition of nocode keyword "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-11-01 07:20 -0700
                Re: Addition of nocode keyword David Spencer <spencer@panix.com> - 2019-10-29 23:46 +0000
                  Re: Addition of nocode keyword "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-10-29 21:41 -0400
                Re: Addition of nocode keyword guinness.tony@gmail.com - 2019-10-30 04:36 -0700
                  Re: Addition of nocode keyword Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-31 00:19 +0000
      Re: Addition of nocode keyword David Brown <david.brown@hesbynett.no> - 2019-10-29 14:32 +0100
        Re: Addition of nocode keyword Jakob Bohm <jb-usenet@wisemo.com.invalid> - 2019-10-29 17:41 +0100
          Re: Addition of nocode keyword David Brown <david.brown@hesbynett.no> - 2019-10-29 23:24 +0100

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

#6010

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:

>I believe nocode is a significant and necessary feature that
>should be added to C, but I'm done trying to work within the
>C Standard oversight body.  I've tried and tried and tried
>and it's not worth it.

>It's easier to write your own language that is backwards com-
>patible with C and be done with it.

This would not be backward compatible with C, which is the main reason
that it would never get consideration past reading the first line of
the submission.

-- 
dhs spencer@panix.com

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

#6013

On 10/28/2019 10:55 PM, David Spencer wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> 
>> I believe nocode is a significant and necessary feature that
>> should be added to C, but I'm done trying to work within the
>> C Standard oversight body.  I've tried and tried and tried
>> and it's not worth it.
> 
>> It's easier to write your own language that is backwards com-
>> patible with C and be done with it.
> 
> This would not be backward compatible with C, which is the main reason
> that it would never get consideration past reading the first line of
> the submission.

Hi David.  Consider:

            (x)
             +----->>> New language
             |
     C ------+----->>> C

At point (x), they would still be the same language.

The new language would be similar to having a C compiler with some
custom extensions.

-- 
Rick C. Hodgin

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

#6019

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:

>On 10/28/2019 10:55 PM, David Spencer wrote:
>Hi David.  Consider:

>            (x)
>             +----->>> New language
>             |
>     C ------+----->>> C

>At point (x), they would still be the same language.

The new language you propose is not the same language at x, or at any
other point.

It would not be compatible with

  int nocode = 0;

which has been C since it was first conceived.

-- 
dhs spencer@panix.com

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

#6020

On Tuesday, October 29, 2019 at 4:21:48 PM UTC-4, David Spencer wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> 
> >On 10/28/2019 10:55 PM, David Spencer wrote:
> >Hi David.  Consider:
> 
> >            (x)
> >             +----->>> New language
> >             |
> >     C ------+----->>> C
> 
> >At point (x), they would still be the same language.
> 
> The new language you propose is not the same language at x, or at any
> other point.
> 
> It would not be compatible with
>   int nocode = 0;
> 
> which has been C since it was first conceived.

New keywords have been added to C with each revision.  At some
point the keyword "auto" did not exist.  int auto = 0; would've
been valid.  It's not any more.

As with all new extensions, things in the past which use the
new keywords / syntax will break.

-- 
Rick C. Hodgin

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

#6021

On Tuesday, October 29, 2019 at 4:31:52 PM UTC-4, Rick C. Hodgin wrote:
> On Tuesday, October 29, 2019 at 4:21:48 PM UTC-4, David Spencer wrote:
...
> > It would not be compatible with
> >   int nocode = 0;
> > 
> > which has been C since it was first conceived.
> 
> New keywords have been added to C with each revision.

Yes, and for quite some time now, the committee has been careful to
choose all new keywords from the name space reserved for
implementations, which therefore cannot cause problems for code that
strictly conformed to previous versions of the standard. I don't think
your suggestion has any significant chance of getting accepted into the
standard, but it would greatly increase that chance to use such a name,
such as _Nocode.

> As with all new extensions, things in the past which use the
> new keywords / syntax will break.

If you choose a reserved name as a keyword, all code which previously
used that keyword was already broken.

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

#6023

On 10/29/2019 5:47 PM, jameskuyper@alumni.caltech.edu wrote:
> On Tuesday, October 29, 2019 at 4:31:52 PM UTC-4, Rick C. Hodgin wrote:
>> On Tuesday, October 29, 2019 at 4:21:48 PM UTC-4, David Spencer wrote:
> ...
>>> It would not be compatible with
>>>    int nocode = 0;
>>>
>>> which has been C since it was first conceived.
>>
>> New keywords have been added to C with each revision.
> 
> Yes, and for quite some time now, the committee has been careful to
> choose all new keywords from the name space reserved for
> implementations, which therefore cannot cause problems for code that
> strictly conformed to previous versions of the standard. I don't think
> your suggestion has any significant chance of getting accepted into the
> standard, but it would greatly increase that chance to use such a name,
> such as _Nocode.

Never happen.  I think the use of features like that in a language,
unless they are explicitly going out of their way to not be invasive
in their name usage, are ridiculous.

     int8_t
     int16_t
     int32_t
     int64_t

Why _t?  In CAlive I defined signed and unsigned:

     s8, s16, s32, s64
     u8, u16, u32, u64

And can you guess what these are?

     f32, f64, f80

>> As with all new extensions, things in the past which use the
>> new keywords / syntax will break.
> 
> If you choose a reserved name as a keyword, all code which previously
> used that keyword was already broken.

Exactly when was "auto" reserved by the C committee?  That C code
I wrote that's been compiling all these years since the 1980s now
breaks because they reserved the word auto in the 1990s?  2000s?
2010s?

It doesn't matter.  I keep saying this, and it's hard for me to
flatly and coldly turn my back on something or someone (it takes
a real chain of events to make it happen), but I'm done with any
attempt to improve C via the C Standard or such related.

CAlive is my future.  End of story.

-- 
Rick C. Hodgin

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

#6026

On 10/29/19 7:36 PM, Rick C. Hodgin wrote:
> On 10/29/2019 5:47 PM, jameskuyper@alumni.caltech.edu wrote:
>> On Tuesday, October 29, 2019 at 4:31:52 PM UTC-4, Rick C. Hodgin wrote:
>>> On Tuesday, October 29, 2019 at 4:21:48 PM UTC-4, David Spencer wrote:
>> ...
>>>> It would not be compatible with
>>>>    int nocode = 0;
>>>>
>>>> which has been C since it was first conceived.
>>>
>>> New keywords have been added to C with each revision.
>>
>> Yes, and for quite some time now, the committee has been careful to
>> choose all new keywords from the name space reserved for
>> implementations, which therefore cannot cause problems for code that
>> strictly conformed to previous versions of the standard. I don't think
>> your suggestion has any significant chance of getting accepted into the
>> standard, but it would greatly increase that chance to use such a name,
>> such as _Nocode.
> 
> Never happen.  I think the use of features like that in a language,
> unless they are explicitly going out of their way to not be invasive
> in their name usage, are ridiculous.
> 
>     int8_t
>     int16_t
>     int32_t
>     int64_t
> 
> Why _t?  In CAlive I defined signed and unsigned:
> 
>     s8, s16, s32, s64
>     u8, u16, u32, u64
> 
> And can you guess what these are?
> 
>     f32, f64, f80
> 
>>> As with all new extensions, things in the past which use the
>>> new keywords / syntax will break.
>>
>> If you choose a reserved name as a keyword, all code which previously
>> used that keyword was already broken.
> 
> Exactly when was "auto" reserved by the C committee?  That C code
> I wrote that's been compiling all these years since the 1980s now
> breaks because they reserved the word auto in the 1990s?  2000s?
> 2010s?

To my memory auto wasn't reserved by the C committee because it was a
key word decades before the C committee touched the language. I am very
sure that auto was a key word in the first publication of K&R back in
the 70s.

the _t endings for the standard integer types was done specifically
BECAUSE it was just ugly enough that those names were very unlikely to
be used in existing code, and the names descriptive enough that even if
they were, they were likely being used for something close enough to
what the standard was defining that the rare conflict was easily fixed.
The problem with type names like s8 was that they WERE fairly commonly
being usedm so even if they were used for similar purposes there was
still a lot of code that needed to be edited to fix it. Also some code
used some of them for something very different, for instance, a program
might define a set of strings as s1, s2, s3, s4, s5, s5, s7, s8 (and hit
the name conflict here).
> It doesn't matter.  I keep saying this, and it's hard for me to
> flatly and coldly turn my back on something or someone (it takes
> a real chain of events to make it happen), but I'm done with any
> attempt to improve C via the C Standard or such related.
> 
> CAlive is my future.  End of story.
> 

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

#6030

On Tuesday, October 29, 2019 at 10:13:09 PM UTC-4, Richard Damon wrote:
> On 10/29/19 7:36 PM, Rick C. Hodgin wrote:
> > Exactly when was "auto" reserved by the C committee?  That C code
> > I wrote that's been compiling all these years since the 1980s now
> > breaks because they reserved the word auto in the 1990s?  2000s?
> > 2010s?
> 
> To my memory auto wasn't reserved by the C committee because it was a
> key word decades before the C committee touched the language. I am very
> sure that auto was a key word in the first publication of K&R back in
> the 70s.

My mistake.  Take some other keyword that wasn't there in the beg-
inning, that was added in later, and use that as a reference for
my point.

-- 
Rick C. Hodgin

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

#6028

On 30/10/2019 00:36, Rick C. Hodgin wrote:
> On 10/29/2019 5:47 PM, jameskuyper@alumni.caltech.edu wrote:
>> On Tuesday, October 29, 2019 at 4:31:52 PM UTC-4, Rick C. Hodgin wrote:
>>> On Tuesday, October 29, 2019 at 4:21:48 PM UTC-4, David Spencer wrote:
>> ...
>>>> It would not be compatible with
>>>>    int nocode = 0;
>>>>
>>>> which has been C since it was first conceived.
>>>
>>> New keywords have been added to C with each revision.
>>
>> Yes, and for quite some time now, the committee has been careful to
>> choose all new keywords from the name space reserved for
>> implementations, which therefore cannot cause problems for code that
>> strictly conformed to previous versions of the standard. I don't think
>> your suggestion has any significant chance of getting accepted into the
>> standard, but it would greatly increase that chance to use such a name,
>> such as _Nocode.
> 
> Never happen.  I think the use of features like that in a language,
> unless they are explicitly going out of their way to not be invasive
> in their name usage, are ridiculous.

The naming style _Nocode is picked /precisely/ not to be invasive - and
is thus an excellent choice.

Look at when C gained a boolean type.  They could not add a keyword
"bool" without conflict with a great deal of existing code.  So the name
of the type, and the new keyword, was _Bool.  But because people often
want a nicer name like "bool", they also made a <stdbool.h> file
consisting basically of :

	#define bool	_Bool
	#define true	1
	#define false	0

It gives you everything.  There is a keyword that does not conflict with
existing code, and people writing new code can easily use the nicer type
name "bool" after #include <stdbool.h>

If your proposal were accepted, the new keyword would be _Nocode.  And
there would be a new standard header, <stdnocode.h>, consisting of the
line :

	#define nocode _Nocode



> 
>     int8_t
>     int16_t
>     int32_t
>     int64_t
> 
> Why _t?

There are a number of reasons.  It makes it obvious to programmers and
readers that these are types, not variables.  It reduces the risk of
conflict with existing code.  It makes them stand out nicely.  They are
long enough that they won't be used for other things, short enough that
the are not onerous to type.  They follow the long tradition in C and
POSIX of using _t suffixes on types.

No choice would be considered "perfect" by everyone, but these names are
good enough for most people.

>  In CAlive I defined signed and unsigned:

Your language, your choice.

> 
>     s8, s16, s32, s64
>     u8, u16, u32, u64

There is such a thing as being /too/ short.  These don't carry the
information I would want in type names - and they risk conflict with
other uses.

> 
> And can you guess what these are?
> 
>     f32, f64, f80

Knowing the context, yes.  Without context, no, it would not be clear.
But "float32_t" and "float64_t" would be perfectly clear in all cases.
(Standard C does not have these types, but I think it should do.)

> 
>>> As with all new extensions, things in the past which use the
>>> new keywords / syntax will break.
>>
>> If you choose a reserved name as a keyword, all code which previously
>> used that keyword was already broken.
> 
> Exactly when was "auto" reserved by the C committee?  That C code
> I wrote that's been compiling all these years since the 1980s now
> breaks because they reserved the word auto in the 1990s?  2000s?
> 2010s?

"auto" has been around since the beginning of C (and perhaps from its
predecessors).  It has been pointless in code since at least C89/C90
(the first standardised C), but still exists for compatibility.  (C++
completely redefined its meaning with C++11.  I would like to see it
deprecated in C too, so that it can be re-used later.)

> 
> It doesn't matter.  I keep saying this, and it's hard for me to
> flatly and coldly turn my back on something or someone (it takes
> a real chain of events to make it happen), but I'm done with any
> attempt to improve C via the C Standard or such related.
> 

I am sure the C standards committee see this as a great loss.

Less sarcastically, the crux of your problem is cooperation.  C is a
language standardised by a committee.  Before changes are made, there
are discussions - opinions are swapped, ideas exchanged.  People
/listen/ far more than they talk, and they think about other people more
than themselves.  The standards committee make changes that they think
will be helpful for /others/ - they are not concerned about their own
coding.

You, on the other hand, are never willing to enter a proper discussion.
 You get an idea, and you fixate on it - convinced that it is something
miraculous and world-changing, and that you alone know the answer.  You
have no consideration for other people - you are concerned only with
your own coding.  You are unable to listen to other people's opinions,
thoughts or suggestions - you assume that anyone who does not agree with
you entirely is doing so through malice or, if you are feeling kind,
incompetence.

/That/ is why you cannot work with the C standards committee.

I hope - though it is highly unlikely - that you will read that and it
will give you the insight needed to change your attitude.  It is always
a good idea to try to work /with/ other people, rather than against
everyone.

> CAlive is my future.  End of story.
> 

Sadly for you, that may be the case.

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

#6032

On Wednesday, October 30, 2019 at 4:48:31 AM UTC-4, David Brown wrote:
> [SNIP SNIP SNIP SNIP SNIP]

DAVID!!!

FOR THE 98TH TIME ... I DO NOT READ YOUR POSTS.  I WILL NEVER
READ YOUR POSTS AGAIN.  I DO NOT WANT YOUR INFLUENCE IN MY LIFE
AT ALL EVER.

STOP POSTING REPLIES TO ME.

IF YOU WANT TO POST A REPLY TO SOMETHING I WRITE, TAKE ALL OF
MY REFERENCES AND ATTRIBUTION OUT OF IT AND QUOTE ONLY THE WORDS
I WROTE WITHOUT ANY ASSOCIATION TO ME, AND THEN REPLY TO THOSE
BLANKENED, GENERIC, FACELESS POINTS.

GOOD-BYE FOREVER!!!

AND LEAVE ME ALONE!!!

-- 
Rick C. Hodgin

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

#6034

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> On Wednesday, October 30, 2019 at 4:48:31 AM UTC-4, David Brown wrote:
>> [SNIP SNIP SNIP SNIP SNIP]
>
> DAVID!!!
>
> FOR THE 98TH TIME ... I DO NOT READ YOUR POSTS.  I WILL NEVER
> READ YOUR POSTS AGAIN.  I DO NOT WANT YOUR INFLUENCE IN MY LIFE
> AT ALL EVER.
>
> STOP POSTING REPLIES TO ME.
>
> IF YOU WANT TO POST A REPLY TO SOMETHING I WRITE, TAKE ALL OF
> MY REFERENCES AND ATTRIBUTION OUT OF IT AND QUOTE ONLY THE WORDS
> I WROTE WITHOUT ANY ASSOCIATION TO ME, AND THEN REPLY TO THOSE
> BLANKENED, GENERIC, FACELESS POINTS.
>
> GOOD-BYE FOREVER!!!
>
> AND LEAVE ME ALONE!!!

Rick, that's not how this works.  David can post whatever he likes.
By posting to Usenet, you give everyone implicit permission to read
and quote what you write.  If you don't like what he posts, ignore
it.  If you use a real newsreader, use a killfile.  (If you use
Google Groups, I don't know whether that's an option, but a Google
search for "google groups killfile" might turn up something useful.)

It's probably useful to let him know (once) that you won't be
reading his posts so he doesn't waste his time, but you don't get
to tell him not to reply to yours.  (Well, you can tell him, but
he can ignore you.)

In a similar vein, my filters are newsgroup-specific.  I was
already filtering out your posts in comp.lang.c.  I will now do so
in comp.std.c.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

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

#6035

On Wednesday, October 30, 2019 at 11:41:13 AM UTC-4, Keith Thompson wrote:
> Rick, that's not how this works.  David can post whatever he likes.

Of course he can.  My request remains.  It's on David now to
honor that request or not.

> [obvious explanation snipped]

-- 
Rick C. Hodgin

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

#6037

On 30/10/2019 17:44, Rick C. Hodgin wrote:
> On Wednesday, October 30, 2019 at 11:41:13 AM UTC-4, Keith Thompson wrote:
>> Rick, that's not how this works.  David can post whatever he likes.
> 
> Of course he can.  My request remains.  It's on David now to
> honor that request or not.
> 

I don't want to get more repetitively off-topic, but the point - as 
Keith explained - is that this is a public newsgroup.  Anything a person 
posts here may be read and quoted by anyone else, and anyone can reply 
to those posts.  Replies in a newsgroup are not personal - they are for 
everyone who accesses the group or its archives, now and in the future. 
Posts may be more or less targeted at a particular poster, but they are 
always for the whole group.

If you want to take the advice or use the information in posts I make, 
great.  If you want to ignore them, that's your choice.  When people 
make informative posts to newsgroups, it is usually in the hope that it 
will be of use or interest to others as well.  If I had wanted to make a 
personal reply to you, Rick, I'd have sent an email.

No, I will not honour any request to avoid following up to Usenet posts 
just because you made the post.  That is not how Usenet works.  I will 
happily honour a request not to make direct contact or email you - 
because that is about personal contact.  But Usenet is public, and you 
don't get to impose gag orders on anyone.

And I really hope that is the end of this particular silliness.

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

#6033

On Tuesday, October 29, 2019 at 7:36:49 PM UTC-4, Rick C. Hodgin wrote:
> On 10/29/2019 5:47 PM, jameskuyper@alumni.caltech.edu wrote:
> > On Tuesday, October 29, 2019 at 4:31:52 PM UTC-4, Rick C. Hodgin wrote:
> >> On Tuesday, October 29, 2019 at 4:21:48 PM UTC-4, David Spencer wrote:
> > ...
> >>> It would not be compatible with
> >>>    int nocode = 0;
> >>>
> >>> which has been C since it was first conceived.
> >>
> >> New keywords have been added to C with each revision.
> > 
> > Yes, and for quite some time now, the committee has been careful to
> > choose all new keywords from the name space reserved for
> > implementations, which therefore cannot cause problems for code that
> > strictly conformed to previous versions of the standard. I don't think
> > your suggestion has any significant chance of getting accepted into the
> > standard, but it would greatly increase that chance to use such a name,
> > such as _Nocode.
> 
> Never happen.  I think the use of features like that in a language,
> unless they are explicitly going out of their way to not be invasive
> in their name usage, are ridiculous.

The following identifiers were given no meaning by C90, but were reserved to the implementation. They were all given specific meanings by later versions of the standard:
_Alignas, _Alignof, _Atomic, _Bool, _Complex, _Generic, _Imaginary,
_Noreturn, _Static_assert, _Thread_local, __func__, __STDC_HOSTED__,
 __STDC_VERSION__, __STDC_ISO_10646__, __STDC_MB_MIGHT_NEQ_WC__,
__STDC_UTF_16__,  __STDC_UTF_32__, __STDC_ANALYZABLE__,
__STDC_IEC_559_COMPLEX__, __STDC_LIB_EXT1__, __STDC_NO_ATOMICS__,
__STDC_NO_COMPLEX__, __STDC_NO_THREADS__, __STDC_NO_VLA__, _Pragma,
_Imaginary_I, _Complex_I, __STDC_WANT_LIB_EXT1__, __alignas_is_defined,
__bool_true_false_are_defined, _Exit.

Because those identifiers were reserved in C90, they could not be used
in strictly conforming C90 code. As a result, the features implemented
by giving standard-defined meanings to those identifiers could be added
to later versions of the language without any danger of breaking
existing strictly conforming code. If you consider that ridiculous -
well, that's just another example of your poor judgment on matters of
language design.

>      int8_t
>      int16_t
>      int32_t
>      int64_t
> 
> Why _t?

POSIX reserves identifiers that end with _t for use in identifying
types. C can be implemented on systems that don't conform to POSIX, but
C was developed in parallel with POSIX, and often follows POSIX
conventions where appropriate.

  In CAlive I defined signed and unsigned:
> 
>      s8, s16, s32, s64
>      u8, u16, u32, u64
> 
> And can you guess what these are?

No. Without the _t, I would suspect them of being variable names, not
types - which is the purpose of that convention. I have in fact used
precisely those identifiers to identify variables, and I've seen the
same use in other people's code. It's particularly common in members
of unions.

> >> As with all new extensions, things in the past which use the
> >> new keywords / syntax will break.
> > 
> > If you choose a reserved name as a keyword, all code which previously
> > used that keyword was already broken.
> 
> Exactly when was "auto" reserved by the C committee?  That C code
> I wrote that's been compiling all these years since the 1980s now
> breaks because they reserved the word auto in the 1990s?  2000s?
> 2010s?

What are you talking about? By any chance are you still compiling using
a C++ compiler, and then once again complaining in a newsgroup devoted
to the C standard about things that went wrong because C++ is a
different language than C?

"auto" has been a keyword for longer than C has been a language. It is,
in fact, a carry over from one of C's predecessor languages (I'm not
sure whether it was introduced in B or in BCPL). It actually made more
sense in the predecessor language. In C, the only places where you're
allowed to use "auto" are places where automatic storage duration is the
default, so leaving out "auto" would give the same result as using it.
As a result, C code almost never uses "auto". Something about it's
predecessor language was different (I'm not sure what) that made "auto"
a reasonable thing to use in that language. 

That's why C++ was able to give "auto" a new meaning, one that probably
broke your code when you compiled it in C++. But that's not the fault of
either committee. There's no good reason to use "auto" in C code, and if
you insist on using a C++ compiler, the new meaning of that keyword is a
good reason why you should not be using it with its old meaning.

> It doesn't matter.  I keep saying this, and it's hard for me to
> flatly and coldly turn my back on something or someone (it takes
> a real chain of events to make it happen), but I'm done with any
> attempt to improve C via the C Standard or such related.

If you're done with it, why are you posting new suggestions to
comp.std.c?

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

#6036

On Wed, 30 Oct 2019 08:12:24 -0700, jameskuyper wrote:
> "auto" has been a keyword for longer than C has been a language. It is,
> in fact, a carry over from one of C's predecessor languages (I'm not
> sure whether it was introduced in B or in BCPL). It actually made more
> sense in the predecessor language. In C, the only places where you're
> allowed to use "auto" are places where automatic storage duration is the
> default, so leaving out "auto" would give the same result as using it.
> As a result, C code almost never uses "auto". Something about it's
> predecessor language was different (I'm not sure what) that made "auto"
> a reasonable thing to use in that language.

In B, local variables are declared like this:

  auto x;

This syntax was permitted and works basically the same way in the original
C standards.  In this specific case, removing 'auto' in fact changes the
meaning of the declaration (so in C90 it was not the case, in general,
that removing "auto" would give the same result as using it).

C99 and later standards completely removed this particular declaration
style from the language; all remaining uses of the auto keyword are truly
redundant.  However most modern C compilers still support this syntax
(with the required diagnostic message) even when they implement recent
standards.

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

#6038

On 10/30/19 12:47 PM, Nick Bowler wrote:
> On Wed, 30 Oct 2019 08:12:24 -0700, jameskuyper wrote:
>> "auto" has been a keyword for longer than C has been a language. It is,
>> in fact, a carry over from one of C's predecessor languages (I'm not
>> sure whether it was introduced in B or in BCPL). It actually made more
>> sense in the predecessor language. In C, the only places where you're
>> allowed to use "auto" are places where automatic storage duration is the
>> default, so leaving out "auto" would give the same result as using it.
>> As a result, C code almost never uses "auto". Something about it's
>> predecessor language was different (I'm not sure what) that made "auto"
>> a reasonable thing to use in that language.
> 
> In B, local variables are declared like this:
> 
>   auto x;
> 
> This syntax was permitted and works basically the same way in the original
> C standards.  In this specific case, removing 'auto' in fact changes the
> meaning of the declaration (so in C90 it was not the case, in general,
> that removing "auto" would give the same result as using it).
> 
> C99 and later standards completely removed this particular declaration
> style from the language; all remaining uses of the auto keyword are truly
> redundant.  However most modern C compilers still support this syntax
> (with the required diagnostic message) even when they implement recent
> standards.
> 

I knew that, and forgot about it, and should have modified my
explanation to accommodate those facts. However, even in C90, that usage
of "auto" could equally well have been handled by typing "int x;", which
involves (very marginally) less typing.

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

#6039

On 30/10/2019 17:47, Nick Bowler wrote:
> On Wed, 30 Oct 2019 08:12:24 -0700, jameskuyper wrote:
>> "auto" has been a keyword for longer than C has been a language. It is,
>> in fact, a carry over from one of C's predecessor languages (I'm not
>> sure whether it was introduced in B or in BCPL). It actually made more
>> sense in the predecessor language. In C, the only places where you're
>> allowed to use "auto" are places where automatic storage duration is the
>> default, so leaving out "auto" would give the same result as using it.
>> As a result, C code almost never uses "auto". Something about it's
>> predecessor language was different (I'm not sure what) that made "auto"
>> a reasonable thing to use in that language.
> 
> In B, local variables are declared like this:
> 
>    auto x;
> 
> This syntax was permitted and works basically the same way in the original
> C standards.  In this specific case, removing 'auto' in fact changes the
> meaning of the declaration (so in C90 it was not the case, in general,
> that removing "auto" would give the same result as using it).

I think that was only because of the "implicit int".  In older C, 
"implicit int" meant that "auto x;" had the same meaning as "auto int 
x;".  Removing the "auto" from that, you'd get "int x;", which would 
have exactly the same meaning (in contexts where "auto int x;" is allowed).

I haven't used B (or BCPL) - could it be that they did not have 
different types, and thus no equivalent of "int x;" ?

> 
> C99 and later standards completely removed this particular declaration
> style from the language; all remaining uses of the auto keyword are truly
> redundant.  However most modern C compilers still support this syntax
> (with the required diagnostic message) even when they implement recent
> standards.
> 

Once "implicit int" was removed from the language, you could no longer 
write "auto x;" - you had to write "auto int x;", "register int x;" or 
just "int x;" (with the auto implied) for a non-static local variable. 
As there is no benefit in including the "auto", it is rarely seen.  But 
compilers /must/ still support "auto int x;" if they try to be 
conforming, as it is still allowed even in modern standards.  And many 
still allow "auto x;" (with implicit int) when compiling in lax modes, 
for support for older code.

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

#6040

On Wed, 30 Oct 2019 18:37:32 +0100, David Brown wrote:
> On 30/10/2019 17:47, Nick Bowler wrote:
>> In B, local variables are declared like this:
>> 
>>    auto x;
>> 
>> This syntax was permitted and works basically the same way in the
>> original C standards.  In this specific case, removing 'auto' in fact
>> changes the meaning of the declaration (so in C90 it was not the case,
>> in general, that removing "auto" would give the same result as using
>> it).
>
> I think that was only because of the "implicit int".  In older C,
> "implicit int" meant that "auto x;" had the same meaning as "auto int
> x;".  Removing the "auto" from that, you'd get "int x;", which would
> have exactly the same meaning (in contexts where "auto int x;" is
> allowed).

This is all true, but as soon as you add 'int' to the declaration the
syntax is no longer compatible with B.  This is probably not a problem
because I doubt there were many programmers who cared about maintaining
B-like syntax in 1999.

> I haven't used B (or BCPL) - could it be that they did not have 
> different types, and thus no equivalent of "int x;" ?

B has no data types (or depending how you look at it, only one type).

Imagine a variant of C where the only object type you are allowed to use
is 'int', and that you can use an 'int' value in any context where you
might want to use a pointer to an int.  Require 'auto' when declaring
local variables, then delete all the 'int' keywords and you'll have a
pretty good idea of what B programs look like.

And if you write a program under this variant, it is quite likely that
it will be successfully translated by a modern C compiler (with warnings),
provided that conversions from int * to int do not lose information (this
is a requirement since B has no pointer types).

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

#6045

David Brown <david.brown@hesbynett.no> writes:
[...]
> Once "implicit int" was removed from the language, you could no longer 
> write "auto x;" - you had to write "auto int x;", "register int x;" or 
> just "int x;" (with the auto implied) for a non-static local variable. 
> As there is no benefit in including the "auto", it is rarely seen.  But 
> compilers /must/ still support "auto int x;" if they try to be 
> conforming, as it is still allowed even in modern standards.  And many 
> still allow "auto x;" (with implicit int) when compiling in lax modes, 
> for support for older code.

Yes, many compilers allow old forms for compatibility with earlier
editions of the standard.  But as far as the standard is concerned,
allowing "auto x;" is no different from allowing any other non-C
syntax.  Backward compatibility extensions have no special status
in the standard; the old forms are simply no longer C.

(Expanding on what you wrote, not disagreeing.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

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

#6042

On 10/30/2019 11:12 AM, jameskuyper@alumni.caltech.edu wrote:
> On Tuesday, October 29, 2019 at 7:36:49 PM UTC-4, Rick C. Hodgin wrote:
>> Exactly when was "auto" reserved by the C committee?  That C code
>> I wrote that's been compiling all these years since the 1980s now
>> breaks because they reserved the word auto in the 1990s?  2000s?
>> 2010s?
> 
> What are you talking about? ...
> 
> "auto" has been a keyword for longer than C has been a language. It is,
> in fact, a carry over from one of C's predecessor languages (I'm not
> sure whether it was introduced in B or in BCPL). It actually made more
> sense in the predecessor language. In C, the only places where you're
> allowed to use "auto" are places where automatic storage duration is the
> default, so leaving out "auto" would give the same result as using it.
> As a result, C code almost never uses "auto". Something about it's
> predecessor language was different (I'm not sure what) that made "auto"
> a reasonable thing to use in that language.

I've never used it.  I didn't even know it was a C language keyword
until I was reading the C Standard the other day.  After reading what
it does I still don't see why it exists.  I came across a website
referencing it that reads:

     "In the language C auto is a keyword for specifying a storage
      duration. When you create an auto variable it has an 'automatic
      storage duration'. We call these objects 'local variables'. In
      C, all variables in functions are local by default. That’s why
      the keyword auto is hardly ever used."

A wasted use of an otherwise desirable functionality as is seen in
C++.

This is what I'm talking about with the C committees being reaction-
ary rather than visionary.  They don't move in ways that make sense.
They move trailing others who are moving in ways they think makes
sense, effectively codifying what's seen in the real world.

It should be more than that.  The C committee should be steering.

> That's why C++ was able to give "auto" a new meaning, one that probably
> broke your code when you compiled it in C++.

There was no code.  It was a fictitious example conjured up to
prove a point.  It would work with any keyword that was later
added to the language.

>> It doesn't matter.  I keep saying this, and it's hard for me to
>> flatly and coldly turn my back on something or someone (it takes
>> a real chain of events to make it happen), but I'm done with any
>> attempt to improve C via the C Standard or such related.
> 
> If you're done with it, why are you posting new suggestions to
> comp.std.c?

I am done with it now after this go around.  I had said previously
I was done with it, but it's very difficult for me to hold rigid
lines on things.  I tend to soften over time.  It takes a very
special set of circumstances to push me to that point and keep me
there.

-- 
Rick C. Hodgin

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

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

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

csiph-web