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 3 of 3 — ← Prev page 1 2 [3]

#6043

On Wednesday, October 30, 2019 at 9:29:28 PM UTC-4, Rick C. Hodgin wrote:
> 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."

It was needed by C's predecessor, B. It remained somewhat useful in C
up until C99, when removal of the implicit int rule also removed what
little remaining usefulness it had. That's the kind of thing that
happens whenever a language lives long enough - if CAlive ever becomes
anything other than vaporware, I'm sure that it will eventually start
accumulating historical artifacts, too.

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

Once something has been standardized, it's extremely difficult,
bordering on the impossible, to remove it if it later turns out to have
been a mistake. "auto" is a prime example of this. Therefore, the
committee generally prefers not to standardize a new feature until after
it has been successfully implemented and put to use as an extension, so
they can get a better idea of whether or not it can work. As a result, C
is generally steered by the implementors, who in turn are often pushed
by their users, rather than being steered by the committee. I don't see
this as a particularly bad thing.

I think your fundamental problem with this process is not who's doing 
the steering, but rather the fact that the people who are doing the
steering are, in general, too competent, sane, and wise to steer the
language in the directions you want it to go (which is not to say that
they're unusually competent, sane, or wise).


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

With the exception of "restrict" all new keywords since C99 have been
chosen from the name space reserved for implementations. It looks like "restrict" is not only the best example you could use, but also probably
the only one. The addition of the other keywords has not broken any
existing strictly conforming code, belying your claim that such breakage
is inevitable.

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

#6044

On Thursday, October 31, 2019 at 11:37:08 AM UTC-4, james...@alumni.caltech.edu wrote:
> On Wednesday, October 30, 2019 at 9:29:28 PM UTC-4, Rick C. Hodgin wrote:
> > 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.
> 
> Once something has been standardized, it's extremely difficult,
> bordering on the impossible, to remove it if it later turns out to have
> been a mistake.

Deprecation is wide-spread in every language I've ever used.  Even
in Java used for mobile Android development.

It is expected that things will migrate / morph over time as newer
and better and different technologies, abilities, features, or what-
ever the cue is, change, that the tools used previously can still
be used if you want those older features, but if you want to move
forward some features need to be faded out.

> "auto" is a prime example of this. Therefore, the
> committee generally prefers not to standardize a new feature until after
> it has been successfully implemented and put to use as an extension, so
> they can get a better idea of whether or not it can work. As a result, C
> is generally steered by the implementors, who in turn are often pushed
> by their users, rather than being steered by the committee. I don't see
> this as a particularly bad thing.

That's what I disagree with.  C should be a steering committee,
as well as a codifying body.

> I think your fundamental problem with this process is not who's doing 
> the steering, but rather the fact that the people who are doing the
> steering are, in general, too competent, sane, and wise to steer the
> language in the directions you want it to go (which is not to say that
> they're unusually competent, sane, or wise).

It's that there is a direction C needs to go.  It needs the class.
It needs to have an option to tighten up type checking.  It needs
some relaxations like not requiring the keyword struct on refer-
ences, single-line comments, anonymous unions, and I think the 2nd
biggest feature:  should not REQUIRE forward declarations.  The
compiler should be allowed to morph into an n-pass compiler where
unresolved forward declarations can be set aside on pass 0, and
then become resolved for pass 1.

To me, these are absolutely fundamental aspects of the nature of
the language.  It calls out for it by its own voice, and not even
by my direction.  When I sit back and look at what a C-like pro-
gramming language needs, this is what IT tells me.

> > > 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.
> 
> With the exception of "restrict" all new keywords since C99 have been
> chosen from the name space reserved for implementations. It looks like "restrict" is not only the best example you could use, but also probably
> the only one. The addition of the other keywords has not broken any
> existing strictly conforming code, belying your claim that such breakage
> is inevitable.

Then use restrict as the example to prove my point.

Deprecation exists for a reason.  You cycle it out 2 or 4 or n
generations, allowing it to be used all that time with the flag
that it's been deprecated, and then remove it.  That gives all
actively software projects / developers plenty of time to make
the changes.  And those that aren't actively developed still run
their old binary code just like always.

It's a different philosophy of use, a different vision I have
for C and C++.  It's why CAlive will be successful.  Many devel-
opers out there have the same wishes I do, they just don't real-
ize it yet because all they have is what they've been given.
But you can look at several new programming languages lately
and the features they incorporate and you can see I'm no alone
in this vision.  My goals are just to keep it closer to C than
other goals.  I want CAlive to compile existing C code with zero
changes and no errors when using a compatibility mode.  It will
just do so with the CAlive LiveCode (edit-and-continue) features,
as well as new ABI features like the inquiry, and several others.

C will be relegated to niche areas increasingly as time goes on.
Other languages running on today's incredibly fast hardware, are
sufficient for 99% of apps.  And in those cases where developers
want more, they won't want to stay at C's low level.  And they
won't want to learn C++'s endless features and nuances to write
clean, efficient C++ code.  They want something simple, useful,
powerful, flexible, easy to develop in/for, easy to update and
maintain, etc.  Enter CAlive's direct target / goals / focus,
coupled also to a faith in Christ applied to the product and its
license, bringing the reality of God back into our daily lives,
yes even our programming lives.  *GASP!*  Yes, we are supposed
to have God active in ALL areas of our lives, not just at a
church on Sundays and Tuesdays for Bible Study.  All the time He
is to be maintained AHEAD of all of our efforts, including every-
thing we do day-in / day-out.

CAlive is coming into existence for a reason.  And oh how I wish
those associated with C would've been more accommodating to new
ideas, having a vision, pushing forward rather than following be-
hind.  It would've saved me years of work.

-- 
Rick C. Hodgin

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

#6046

On 31/10/2019 17:38, Rick C. Hodgin wrote:
> On Thursday, October 31, 2019 at 11:37:08 AM UTC-4, james...@alumni.caltech.edu wrote:
>> On Wednesday, October 30, 2019 at 9:29:28 PM UTC-4, Rick C. Hodgin wrote:
>>> 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.
>>
>> Once something has been standardized, it's extremely difficult,
>> bordering on the impossible, to remove it if it later turns out to have
>> been a mistake.
> 
> Deprecation is wide-spread in every language I've ever used.  Even
> in Java used for mobile Android development.
> 

A very important feature of C as a language is that it does /not/ 
deprecate anything without very good reason.  C does not gain new 
features easily - and it loses features even more reluctantly.  This is 
both a benefit and a limitation - but the C community (compiler vendors, 
programmers, and standards committee) have taken the view that C is to 
be a stable language.  This means - unlike many other languages - you 
can take old C code, compile it with a new C compiler (on a platform 
that didn't exist when the code was written), and have a good chance of 
everything working correctly.  The disadvantage is that the language 
does not gain much in the way of new features - C is what it is, and 
your choice is to accept that or find a different language.

I have personally made updated versions of C programs I wrote over 
twenty years ago, and the language still works the same on modern tools.

 From the C99 Rationale:

"""
The Committee is content to let C++ be the big and ambitious language. 
While some features of C++ may well be embraced, it is not the 
Committee’s intention that C become C++.
"""

Indeed, I'd recommend reading the entire introduction to the C99 
Rationale to get an idea of how C changes.

> It is expected that things will migrate / morph over time as newer
> and better and different technologies, abilities, features, or what-
> ever the cue is, change, that the tools used previously can still
> be used if you want those older features, but if you want to move
> forward some features need to be faded out.

That is common, but not necessary - and while it is often not a problem, 
it is not always desirable.  That is why there is a place for a stable 
language like C, as well as more innovative and faster-changing languages.

> 
>> "auto" is a prime example of this. Therefore, the
>> committee generally prefers not to standardize a new feature until after
>> it has been successfully implemented and put to use as an extension, so
>> they can get a better idea of whether or not it can work. As a result, C
>> is generally steered by the implementors, who in turn are often pushed
>> by their users, rather than being steered by the committee. I don't see
>> this as a particularly bad thing.
> 
> That's what I disagree with.  C should be a steering committee,
> as well as a codifying body.

The C community as a whole disagrees with you.  You may want a more 
top-down for your own languages (and top-down has its benefits too), but 
that is not the way C works.

> 
>> I think your fundamental problem with this process is not who's doing
>> the steering, but rather the fact that the people who are doing the
>> steering are, in general, too competent, sane, and wise to steer the
>> language in the directions you want it to go (which is not to say that
>> they're unusually competent, sane, or wise).
> 
> It's that there is a direction C needs to go.  

Why?  C is fine as it is, receiving mostly just small fixes or improvements.

> It needs the class.

No, it does not.  That would give you a different language.  There are 
already plenty of languages that are a bit like C, but have classes - 
there is no need for C to become one of them.

> It needs to have an option to tighten up type checking.  It needs
> some relaxations like not requiring the keyword struct on refer-
> ences, single-line comments, anonymous unions, and I think the 2nd
> biggest feature:  should not REQUIRE forward declarations.  The
> compiler should be allowed to morph into an n-pass compiler where
> unresolved forward declarations can be set aside on pass 0, and
> then become resolved for pass 1.

Single-line comments were added in C99, and anonymous unions moved from 
a very common extension to standard in C11.  Surely it is a good idea to 
learn what the C language and the C standards say, before criticising it?

> 
> To me, these are absolutely fundamental aspects of the nature of
> the language.

Then you are not talking about C.  They may well be features you like to 
see in programming languages - everyone has their own preferences and 
opinions.  But you cannot call them "absolutely fundamental aspects of 
the nature of the language", given that the C language has been in heavy 
use for about 50 years and does not have these features!

>  It calls out for it by its own voice, and not even
> by my direction.  When I sit back and look at what a C-like pro-
> gramming language needs, this is what IT tells me.
> 

This is all your personal opinion and preferences, nothing more.  If you 
feel that strongly, then use a different programming language that has 
the features you want, not C.  You can't blame C for not being the 
language you want to use - that's just silly.  It's like blaming an 
apple pie for not tasting chocolaty when chocolate cake is your favourite.

>>>> 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.
>>
>> With the exception of "restrict" all new keywords since C99 have been
>> chosen from the name space reserved for implementations. It looks like "restrict" is not only the best example you could use, but also probably
>> the only one. The addition of the other keywords has not broken any
>> existing strictly conforming code, belying your claim that such breakage
>> is inevitable.
> 
> Then use restrict as the example to prove my point.
> 
> Deprecation exists for a reason.  You cycle it out 2 or 4 or n
> generations, allowing it to be used all that time with the flag
> that it's been deprecated, and then remove it.  That gives all
> actively software projects / developers plenty of time to make
> the changes.  And those that aren't actively developed still run
> their old binary code just like always.
> 
> It's a different philosophy of use, a different vision I have
> for C and C++.  It's why CAlive will be successful.  Many devel-
> opers out there have the same wishes I do, they just don't real-
> ize it yet because all they have is what they've been given.
> But you can look at several new programming languages lately
> and the features they incorporate and you can see I'm no alone
> in this vision.  My goals are just to keep it closer to C than
> other goals.  I want CAlive to compile existing C code with zero
> changes and no errors when using a compatibility mode.  It will
> just do so with the CAlive LiveCode (edit-and-continue) features,
> as well as new ABI features like the inquiry, and several others.
> 
> C will be relegated to niche areas increasingly as time goes on.

Odd - C has existed for 50 years or so, and is still hugely popular and 
important.  Most other languages either remain niche, or are popular for 
a few years before fading away.  Your claims are completely disconnected 
from reality.

> Other languages running on today's incredibly fast hardware, are
> sufficient for 99% of apps.  And in those cases where developers
> want more, they won't want to stay at C's low level.

No one has ever suggested that C is the best language choice for all 
use.  Most people use C for coding problems that suit C, and other 
languages for coding problems best solved in other languages.

>  And they
> won't want to learn C++'s endless features and nuances to write
> clean, efficient C++ code.

One of the few challengers to C for a long-lived and endlessly popular 
language, is C++.

>  They want something simple, useful,
> powerful, flexible, easy to develop in/for, easy to update and
> maintain, etc.

People who want that, use other languages.  There are lots to choose from.

>  Enter CAlive's direct target / goals / focus,
> coupled also to a faith in Christ applied to the product and its
> license, bringing the reality of God back into our daily lives,
> yes even our programming lives.  *GASP!*  Yes, we are supposed
> to have God active in ALL areas of our lives, not just at a
> church on Sundays and Tuesdays for Bible Study.  All the time He
> is to be maintained AHEAD of all of our efforts, including every-
> thing we do day-in / day-out.
> 

If that's what you want, that's fine for /you/ - and anyone who shares 
your opinions and preferences.  But it does not mean there is something 
wrong with C (or any other language).

> CAlive is coming into existence for a reason.  And oh how I wish
> those associated with C would've been more accommodating to new
> ideas, having a vision, pushing forward rather than following be-
> hind.  It would've saved me years of work.
> 

Did it never occur to you that no one who works with C was interested in 
any of your ideas?  An idea being "new" does not automatically make it a 
good idea - and even an idea that is good for some programming languages 
is not automatically good for other languages.  I have heard countless 
ideas from you over the years, and there were barely two or three that I 
ever thought had useful potential for any programming language - none 
that made sense for C.  (There were more that could have been turned 
into good ideas, had you been open to discussion.)  If you think your 
ideas will let you build a wonderful new language "CAlive", then great - 
go for it.  But please cut out the delusion that you alone know what is 
good for C.

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

#6141

Am 31.10.19 um 02:29 schrieb Rick C. Hodgin:
> 
> 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.

While you might disagree with how the comitee works, the current way has
even been stated explicitly. From the C2X charter N2086:

"8. Codify existing practice to address evident deficiencies. Only those
concepts that have some prior art should be accepted. (Prior art may
come from implementations of languages other than C.) Unless some
proposed new feature addresses an evident deficiency that is actually
felt by more than a few C programmers, no new inventions should be
entertained."

"13. Unlike for C99, the consensus at the London meeting was that there
should be no invention, without exception. Only those features that have
a history and are in common use by a commercial implementation should be
considered. Also there must be care to standardize these features in a
way that would make the Standard and the commercial implementation
compatible."

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

#6047

On Wednesday, October 30, 2019 at 11:12:26 AM UTC-4, james...@alumni.caltech.edu wrote:
> On Tuesday, October 29, 2019 at 7:36:49 PM UTC-4, Rick C. Hodgin wrote:
> >      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?
> 
> No. Without the _t, I would suspect them of being variable names, not
> types - which is the purpose of that convention.

What is "int"?  I come from an assembly background.  INT is an
interrupt.  Okay, so in C int is an integer.  Got it.

You learn what key / core features of a language are and then
use them as foundations.  The same holds true for s8, s16, s32,
s64, and u8, u16, u32, u64.  I also define other forms which
auto-upsize in use, including s24, s40, s48, s54, and their u
counterparts.  They allow for packed data storage of unusual
sizes.

When I first heard the website Yahoo, or the website YouTube,
I thought those were ridiculous names.  It would be like me
coming up with MeTalkie for a communications website.  It may
sound silly today, but if it were popular it would just be a
name.

I once was talking to my computer illiterate neighbors who
needed help getting on the Internet and getting setup with
Windows 98 at that time.

The mother and the daughter were there, and I asked them this
literal question:  "Is your web browser home page set to
launch into Yahoo.com?"  And they both burst out laughing so
hard they started crying.  They had no idea what I was talking
about, and only knew the words from everyday experience.  We
still talk about that day.  And when you look at that question
from that point of view, it really is quite a series of words
strung together.

Some of C's syntax is quite a thing.  C++ even more so.  But
once you get used to it, become fluent in it, it's all as it
should be.

We learn by doing, James.  It's true of all things, including
programming languages.  But I'll still argue all day long that
tagging things that will be used in every function with an _t
is beyond ridiculous, into a whole new realm of even-more-than-
ridiculous.  It forces you to create your own typedefs or
#define statements to make them something more desirable.

-- 
Rick C. Hodgin

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

#6024

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

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

So it's not backward compatible.  Stop claiming that it is.

-- 
dhs spencer@panix.com

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

#6025

On 10/29/2019 7:46 PM, David Spencer wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>> As with all new extensions, things in the past which use the
>> new keywords / syntax will break.
> 
> So it's not backward compatible.  Stop claiming that it is.


Really, David?

-- 
Rick C. Hodgin

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

#6029

On Tuesday, 29 October 2019 20:31:52 UTC, Rick C. Hodgin  wrote:
> 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.

At what point did C not have the keyword 'auto'?

It's present even in the earliest C manual I can find:
https://www.bell-labs.com/usr/dmr/www/cman.pdf

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

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

#6041

guinness.tony@gmail.com writes:

> On Tuesday, 29 October 2019 20:31:52 UTC, Rick C. Hodgin  wrote:
<cut>
>> 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.
>
> At what point did C not have the keyword 'auto'?
>
> It's present even in the earliest C manual I can find:
> https://www.bell-labs.com/usr/dmr/www/cman.pdf

It's also in C's predecessor B.  I think it's safe to say it has always
been in C, even before C was publicly described.

-- 
Ben.

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

#6017

On 28/10/2019 10:42, Jakob Bohm wrote:

> 
> For clarity, a number of existing compilers have the following known 
> warning behavior:
> 
> In places where empty statements are likely to be typos etc., they warn 
> about an actual empty statement (such as a lone semicolon), but accept 
> an empty block as en explicit request that nothing be done, without that 
> warning.
> 
> Typical examples include:
> 
>   if (x > 3) ; // Warns about possible typo
>      puts("x is greater than 3");
>   if (x > 3) {} // No warning
>   puts("Hello world");
> 

Good tools try to warn about potentially unintentional code or
behaviour.  It is not always easy to avoid false positives, however.
That is why more advanced tools (linters) often use stylised comments as
additional information.

> In general, it would be useful to supplement the C standard with some 
> statements of best practice for implementations, such as:

When you say "supplement the C standard", do you mean you think these
should be added to the C standards (in which case I disagree entirely),
or that there should be in a supplemental document that can be used
along with the C standards (in which case I mostly disagree) ?

Pretty much everything you suggest below is in the category of "quality
of implementation" - they are features that a compiler can support in
order to be a more useful development tool for users.  They are not
about C coding, or the functional behaviour of the code - and thus not
something that should be part of the C standards.  They are merely
useful warnings and diagnostic information - and can be provided by
non-compiler tools (linters, or even IDE's), and could be a significant
implementation burden for small compilers.

> 
>   * Warn about empty controlled statements
>   * Diagnostics should point to the exact code location and mention 
> the items involved.
>   * Diagnostics involving include files should state both the include 
> file and where it was included.
>   * Diagnostics involving macros should state both the location of the 
> invocation and the location of the specific location within the macro 
> definition.
>   * Diagnostics involving continuation lines should point to actual 
> source file lines, not abstract decoded lines.

These are all just compiler warnings.


>   * Unless otherwise stated, basic types should expose whatever behavior 
> above and beyond the language standard that is provided by the actual 
> machine definition.  (For example, unless otherwise stated, if the 
> machine is one that is defined to handle integer overflow in a specific 
> way, that behavior should be implementation defined to be that machine 
> behavior, not "anything goes" undefined).

This is a terrible idea in terms of portability of C code, and
optimisation of C code.

If a compiler wants to provide additional documented semantics for
things that the C standards do not define, such as integer overflow
behaviour, then it can do so.  Even better, compilers can provide
choices to control this behaviour (I would strongly prefer such choices
to be made in the code, such as by pragmas, rather than command-line
switches).

But there are many disadvantages in having such extra behaviour - it
reduces optimisation opportunities, it reduces static error checking,
and it reduces run-time diagnostics and checks.  And of course it
encourages code to be unnecessarily tied to specific platforms.

I can appreciate that some people want specific behaviour for integer
overflow - I am convinced that many of these do not appreciate the
negative consequences of that behaviour.  And many people specifically
do not want such behaviour.  So it certainly should not be mandated by
the standards.


>   * With very few clearly implementation defined cases, "undefined 
> behavior" is not a license to introduce semantics that bear no 
> resemblance to the source code.  (A typical implementation defined case 
> would be a function-like keyword that explicitly tells the compiler to 
> ignore certain cases in its interpretation of the program).  It can 
> however be a license to arbitrarily choose between different meaningful 
> interpretations, such as performing memory accesses in either of 
> multiple permitted orders or optimizing an expression in ways that are 
> not correct for invalid inputs, provided this does not trigger mistaken 
> optimization assumptions outside the expression.
> 

Undefined behaviour has, by its definition, no meaningful behaviour.  In
some cases it might be possible to guess what the programmer intended,
though this can be very difficult to do in a deterministic way in a
compiler - what is "obvious" to a human reader in a simple sample case
may be very much harder to spot in general cases in a tool.

It is reasonable to want a compiler that does not knowingly exasperate
problems due to undefined behaviour - that is a quality of
implementation issue.  But it is unreasonable (indeed, impossible) to
attempt to legislate this in general.

There may be scope for changing certain /specific/ cases of undefined
behaviour in the standards into fully defined or implementation specific
behaviour.  But it would be for specific cases only, not as a
generalisation.

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

#6018

On 29/10/2019 14:32, David Brown wrote:
> On 28/10/2019 10:42, Jakob Bohm wrote:
> 
>>
>> For clarity, a number of existing compilers have the following known
>> warning behavior:
>>
>> In places where empty statements are likely to be typos etc., they warn
>> about an actual empty statement (such as a lone semicolon), but accept
>> an empty block as en explicit request that nothing be done, without that
>> warning.
>>
>> Typical examples include:
>>
>>    if (x > 3) ; // Warns about possible typo
>>       puts("x is greater than 3");
>>    if (x > 3) {} // No warning
>>    puts("Hello world");
>>
> 

Note: The above was an example of actual good behavior by some actual
current compilers, given as a counterexample to the proposal for a
"nocode" keyword.

> Good tools try to warn about potentially unintentional code or
> behaviour.  It is not always easy to avoid false positives, however.
> That is why more advanced tools (linters) often use stylised comments as
> additional information.
> 
>> In general, it would be useful to supplement the C standard with some
>> statements of best practice for implementations, such as:
> 
> When you say "supplement the C standard", do you mean you think these
> should be added to the C standards (in which case I disagree entirely),
> or that there should be in a supplemental document that can be used
> along with the C standards (in which case I mostly disagree) ?
> 
> Pretty much everything you suggest below is in the category of "quality
> of implementation" - they are features that a compiler can support in
> order to be a more useful development tool for users.  They are not
> about C coding, or the functional behaviour of the code - and thus not
> something that should be part of the C standards.  They are merely
> useful warnings and diagnostic information - and can be provided by
> non-compiler tools (linters, or even IDE's), and could be a significant
> implementation burden for small compilers.
> 

Indeed this would be a separate "quality of implementation" document,
covering many aspects ignored by the formal requirements of the C
standard.  Such a document, with a reasonably level of independence and
authority behind it, could allow purchase managers and formal tenders
for public contracts to state that they want a compiler that is at least
"quality level 2" or for portable C libraries to state that it is
portable to all "quality level 2" compilers.


>>
>>    * Warn about empty controlled statements
>>    * Diagnostics should point to the exact code location and mention
>> the items involved.
>>    * Diagnostics involving include files should state both the include
>> file and where it was included.
>>    * Diagnostics involving macros should state both the location of the
>> invocation and the location of the specific location within the macro
>> definition.
>>    * Diagnostics involving continuation lines should point to actual
>> source file lines, not abstract decoded lines.
> 
> These are all just compiler warnings.

The last 4 also apply to error diagnostics.  Over the years I have
encountered a number of otherwise good compilers failing each of these
rules, making it very difficult to identify what exactly triggered that
"syntax error" diagnostic.


> 
> 
>>    * Unless otherwise stated, basic types should expose whatever behavior
>> above and beyond the language standard that is provided by the actual
>> machine definition.  (For example, unless otherwise stated, if the
>> machine is one that is defined to handle integer overflow in a specific
>> way, that behavior should be implementation defined to be that machine
>> behavior, not "anything goes" undefined).
> 
> This is a terrible idea in terms of portability of C code, and
> optimisation of C code.
> 
> If a compiler wants to provide additional documented semantics for
> things that the C standards do not define, such as integer overflow
> behaviour, then it can do so.  Even better, compilers can provide
> choices to control this behaviour (I would strongly prefer such choices
> to be made in the code, such as by pragmas, rather than command-line
> switches).

The ability to choose different semantics for compiler specific reason
is why I wrote "unless otherwise stated" twice.

> 
> But there are many disadvantages in having such extra behaviour - it
> reduces optimisation opportunities, it reduces static error checking,
> and it reduces run-time diagnostics and checks.  And of course it
> encourages code to be unnecessarily tied to specific platforms.
> 

In practice, the vast majority of machines share some common semantics
such as "2s complement ints" or "ints stored as straight little or big
endian, nothing weird".

> I can appreciate that some people want specific behaviour for integer
> overflow - I am convinced that many of these do not appreciate the
> negative consequences of that behaviour.  And many people specifically
> do not want such behaviour.  So it certainly should not be mandated by
> the standards.
> 

I have yet to see anyone outside academia and compiler vendors actively
wanting the bizarro optimizations found e.g. in some versions of gcc.

I have seen those that want explicit overflow semantics such as
saturation to MAXINT/MININT (for the actual type), or program
termination with a diagnostic, as either ensures that out-of-range
values do not cause unexpected malfunctions (think Ariane rocket
incident).

The point is to state that it is a horribly bad (even if compliant)
compiler that does what some gcc versions reportedly did (optimizing
away a loop condition because the loop would assign an out-of-range
value to a variable which would not be read after assigning that invalid
value).


> 
>>    * With very few clearly implementation defined cases, "undefined
>> behavior" is not a license to introduce semantics that bear no
>> resemblance to the source code.  (A typical implementation defined case
>> would be a function-like keyword that explicitly tells the compiler to
>> ignore certain cases in its interpretation of the program).  It can
>> however be a license to arbitrarily choose between different meaningful
>> interpretations, such as performing memory accesses in either of
>> multiple permitted orders or optimizing an expression in ways that are
>> not correct for invalid inputs, provided this does not trigger mistaken
>> optimization assumptions outside the expression.
>>
> 
> Undefined behaviour has, by its definition, no meaningful behaviour.  In
> some cases it might be possible to guess what the programmer intended,
> though this can be very difficult to do in a deterministic way in a
> compiler - what is "obvious" to a human reader in a simple sample case
> may be very much harder to spot in general cases in a tool.
> 

Indeed, that is how the compiler community has chosen to read it, while
historic C compilers (from around the time of the C89 definition) would
interpret it as simply "not defined by the standard, do something sane
and preferably documented".

> It is reasonable to want a compiler that does not knowingly exasperate
> problems due to undefined behaviour - that is a quality of
> implementation issue.  But it is unreasonable (indeed, impossible) to
> attempt to legislate this in general.
> 

The somewhat obtuse misreadings of the standard by all major compiler
vendors in recent years is at least reason to explicitly make such
misreadings invalid.

> There may be scope for changing certain /specific/ cases of undefined
> behaviour in the standards into fully defined or implementation specific
> behaviour.  But it would be for specific cases only, not as a
> generalisation.
> 

The proposal is to change the default meaning of "undefined behavior" to
"implementation specific" in all but a few clearly delineated cases.
Of cause an implementation could define an insane implementation
specific behavior, but it would stick out as a sore thumb to anyone
reading the "implementation specific behavior" section of the 
documentation, unlike a mostly undocumented obtuse interpretation.



Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

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

#6022

On 29/10/2019 17:41, Jakob Bohm wrote:
> On 29/10/2019 14:32, David Brown wrote:
>> On 28/10/2019 10:42, Jakob Bohm wrote:
>>
>>>
>>> For clarity, a number of existing compilers have the following known
>>> warning behavior:
>>>
>>> In places where empty statements are likely to be typos etc., they warn
>>> about an actual empty statement (such as a lone semicolon), but accept
>>> an empty block as en explicit request that nothing be done, without that
>>> warning.
>>>
>>> Typical examples include:
>>>
>>>    if (x > 3) ; // Warns about possible typo
>>>       puts("x is greater than 3");
>>>    if (x > 3) {} // No warning
>>>    puts("Hello world");
>>>
>>
> 
> Note: The above was an example of actual good behavior by some actual
> current compilers, given as a counterexample to the proposal for a
> "nocode" keyword.
> 

Yes, I agree - both that such compiler warnings are useful, and that 
they show a "nocode" keyword is unnecessary.

>> Good tools try to warn about potentially unintentional code or
>> behaviour.  It is not always easy to avoid false positives, however.
>> That is why more advanced tools (linters) often use stylised comments as
>> additional information.
>>
>>> In general, it would be useful to supplement the C standard with some
>>> statements of best practice for implementations, such as:
>>
>> When you say "supplement the C standard", do you mean you think these
>> should be added to the C standards (in which case I disagree entirely),
>> or that there should be in a supplemental document that can be used
>> along with the C standards (in which case I mostly disagree) ?
>>
>> Pretty much everything you suggest below is in the category of "quality
>> of implementation" - they are features that a compiler can support in
>> order to be a more useful development tool for users.  They are not
>> about C coding, or the functional behaviour of the code - and thus not
>> something that should be part of the C standards.  They are merely
>> useful warnings and diagnostic information - and can be provided by
>> non-compiler tools (linters, or even IDE's), and could be a significant
>> implementation burden for small compilers.
>>
> 
> Indeed this would be a separate "quality of implementation" document,
> covering many aspects ignored by the formal requirements of the C
> standard.  Such a document, with a reasonably level of independence and
> authority behind it, could allow purchase managers and formal tenders
> for public contracts to state that they want a compiler that is at least
> "quality level 2" or for portable C libraries to state that it is
> portable to all "quality level 2" compilers.
> 

Ah, okay.  I think it would be difficult to specify these things 
accurately enough for a document like that, but I now understand more 
about what you mean.  Perhaps it would be better expressed as a kind of 
test suite - a set of example snippets that you expect "quality" 
compilers to emit warnings on, plus other snippets that you /don't/ want 
warnings on.  People could rate compilers (or, more specifically, 
compiler + flag combinations) on the percentage of matches on the tests.

> 
>>>
>>>    * Warn about empty controlled statements
>>>    * Diagnostics should point to the exact code location and mention
>>> the items involved.
>>>    * Diagnostics involving include files should state both the include
>>> file and where it was included.
>>>    * Diagnostics involving macros should state both the location of the
>>> invocation and the location of the specific location within the macro
>>> definition.
>>>    * Diagnostics involving continuation lines should point to actual
>>> source file lines, not abstract decoded lines.
>>
>> These are all just compiler warnings.
> 
> The last 4 also apply to error diagnostics.  Over the years I have
> encountered a number of otherwise good compilers failing each of these
> rules, making it very difficult to identify what exactly triggered that
> "syntax error" diagnostic.
> 

I am afraid you will continue to be disappointed, because you are asking 
about an unsolvable problem.  Compilers can get better at this - and in 
my experience, they /are/ getting better - but they can never get it 
fully right.  If you write "int colour;" in one part of a file, and 
later write "color = 2;" in another part, which line is the mistake?

Compilers - especially combined with a good IDE - can make it easier to 
find the source of diagnostics, but they won't ever get it perfect.


> 
>>
>>
>>>    * Unless otherwise stated, basic types should expose whatever 
>>> behavior
>>> above and beyond the language standard that is provided by the actual
>>> machine definition.  (For example, unless otherwise stated, if the
>>> machine is one that is defined to handle integer overflow in a specific
>>> way, that behavior should be implementation defined to be that machine
>>> behavior, not "anything goes" undefined).
>>
>> This is a terrible idea in terms of portability of C code, and
>> optimisation of C code.
>>
>> If a compiler wants to provide additional documented semantics for
>> things that the C standards do not define, such as integer overflow
>> behaviour, then it can do so.  Even better, compilers can provide
>> choices to control this behaviour (I would strongly prefer such choices
>> to be made in the code, such as by pragmas, rather than command-line
>> switches).
> 
> The ability to choose different semantics for compiler specific reason
> is why I wrote "unless otherwise stated" twice.
> 

Yes - but I strongly disagree with your wish to make these extra 
semantics the default.  Change it to be "compilers should have a way to 
expose stronger semantics of integer arithmetic convenient to the 
underlying machine", and I would be a lot happier.  Even better would be 
for compilers to provide types like "int_mod32_t" which would be a 
32-bit signed integer with modular overflow behaviour.  "int32_t" (and 
"int") would continue to have undefined overflow behaviour.  Then the 
programmer would be stating exactly what they want.

>>
>> But there are many disadvantages in having such extra behaviour - it
>> reduces optimisation opportunities, it reduces static error checking,
>> and it reduces run-time diagnostics and checks.  And of course it
>> encourages code to be unnecessarily tied to specific platforms.
>>
> 
> In practice, the vast majority of machines share some common semantics
> such as "2s complement ints" or "ints stored as straight little or big
> endian, nothing weird".

You are mixing representation and operational semantics.

That is a matter of representation, and it is certainly the case that 
for modern processors, two's complement with big or little endian 
ordering and no padding is universal.  (There are still systems in use 
for which this does not apply, but they are unlikely to have compilers 
that support future C standards.)  Sizes are not as universal as some 
people think - there are devices in use with 16-bit or 32-bit char, or 
with 24-bit int.

I have nothing against simplifying the C standards to require two's 
complement representation and ban padding bits (except in _Bool).  C++20 
has this, and it is a proposed addition to the next C standard.

However, representation is not overflow behaviour.  There are very good 
reasons for /not/ wanting two's complement overflow behaviour even when 
the underlying cpu supports it.

(There are some operations, especially with shifts, where it would be 
reasonable to tighten the behaviour definitions if the representation is 
fixed with two's complement.  And things like conversions from unsigned 
to signed types could be given fully defined behaviour rather than 
implementation defined behaviour.)

> 
>> I can appreciate that some people want specific behaviour for integer
>> overflow - I am convinced that many of these do not appreciate the
>> negative consequences of that behaviour.  And many people specifically
>> do not want such behaviour.  So it certainly should not be mandated by
>> the standards.
>>
> 
> I have yet to see anyone outside academia and compiler vendors actively
> wanting the bizarro optimizations found e.g. in some versions of gcc.
> 

Well, that's changed now.  I write code for small embedded systems, 
mainly in C (with some C++), and I want signed overflow to be undefined 
behaviour, and I want the compiler to optimise based on that knowledge. 
I want my compiler to transform "x + 1 > 0" into "x >= 0".  I want it to 
transform "x * 20 / 5" into "x * 4".  I want it to inform me if I've 
written "int x = 1000000 * 1000000;".  I want it to be able to run with 
"-fsanitize=integer-overflow" and tell me when it sees a mistake in my code.

Overflowing your types is almost always an error in the code.  (Not 
always, but almost always.  I am happy to go out of my way to deal with 
cases where I actually want wrapping behaviour.)  I want my compiler to 
be able to tell me if it sees these errors, and I want it to be able to 
optimise on the assumption that those errors don't occur.

> I have seen those that want explicit overflow semantics such as
> saturation to MAXINT/MININT (for the actual type), 

Yes, sometimes you want saturation behaviour.

> or program
> termination with a diagnostic, as either ensures that out-of-range
> values do not cause unexpected malfunctions (think Ariane rocket
> incident).

Making integer overflow defined behaviour means errors like this are 
more likely - because they are still logical errors in the code, but now 
they are allowed by the language and the tools have no way to distinguish.

> 
> The point is to state that it is a horribly bad (even if compliant)
> compiler that does what some gcc versions reportedly did (optimizing
> away a loop condition because the loop would assign an out-of-range
> value to a variable which would not be read after assigning that invalid
> value).
> 

Let's be clear here - the famous case of gcc removing a loop 
optimisation in  SPEC benchmark was due to a bug in the SPEC code, and 
was with a pre-release test version of gcc.  Part of the testing before 
releasing new compiler versions involves such tests, and the whole thing 
was only publicised because it was interesting that a bug had been found 
in the old SPEC code.

When you write code with undefined behaviour, you cannot expect the 
compiler to guess what you meant to write.  If you think that is the 
case, C is not the language for you - it is that simple.

Having said that, compilers can always be better at informing the user 
about such cases.  They cannot tell you whenever they optimises based on 
the assumption that undefined behaviour does not occur - then perfectly 
normal code would cause a flood of warnings.  But they can always be better.

> 
>>
>>>    * With very few clearly implementation defined cases, "undefined
>>> behavior" is not a license to introduce semantics that bear no
>>> resemblance to the source code.  (A typical implementation defined case
>>> would be a function-like keyword that explicitly tells the compiler to
>>> ignore certain cases in its interpretation of the program).  It can
>>> however be a license to arbitrarily choose between different meaningful
>>> interpretations, such as performing memory accesses in either of
>>> multiple permitted orders or optimizing an expression in ways that are
>>> not correct for invalid inputs, provided this does not trigger mistaken
>>> optimization assumptions outside the expression.
>>>
>>
>> Undefined behaviour has, by its definition, no meaningful behaviour.  In
>> some cases it might be possible to guess what the programmer intended,
>> though this can be very difficult to do in a deterministic way in a
>> compiler - what is "obvious" to a human reader in a simple sample case
>> may be very much harder to spot in general cases in a tool.
>>
> 
> Indeed, that is how the compiler community has chosen to read it, while
> historic C compilers (from around the time of the C89 definition) would
> interpret it as simply "not defined by the standard, do something sane
> and preferably documented".

No, compilers have never done that - it's a common myth and 
misunderstanding.  Lack of optimisations in earlier compilers was due to 
more limited knowledge of compilers and optimisation techniques, and 
more limited resources on hosts.  And even 30 years ago, compilers /did/ 
optimise on the assumption that integer overflow did not occur - such as 
strength-reduction of "x * 20 / 5" to "x * 4".  And there are also many 
cases where compilers have said "this is not defined by the standard, 
but we choose to define it ourselves".

> 
>> It is reasonable to want a compiler that does not knowingly exasperate
>> problems due to undefined behaviour - that is a quality of
>> implementation issue.  But it is unreasonable (indeed, impossible) to
>> attempt to legislate this in general.
>>
> 
> The somewhat obtuse misreadings of the standard by all major compiler
> vendors in recent years is at least reason to explicitly make such
> misreadings invalid.

Every compiler vendor I know of would want to hear about any misreadings 
they have made.  Have you considered that they in fact /have/ read the 
standards correctly, instead of making up additional ideas that are not 
there in the standards?  If you can point to the wording in the 
published C standards (C90, C99, C11 or C18) showing where integer 
overflow behaviour is defined to be wrapping two's complement behaviour 
on two's complement cpus, then you would have a strong point.


There are many challenges involved in writing good, efficient, and 
portable C code.  One of these is that there are bits of code that can 
be written in a way that is undefined behaviour and fails on stronger 
compilers but works efficiently on weaker compilers, or it can be 
written in another way that is defined behaviour and works efficiently 
on strong compilers but very inefficiently on weaker compilers.  Which 
way should you write such code?  The answer is, of course, "it depends". 
  What you cannot reasonably do, however, is place artificial limits on 
good, modern compilers in order to support older code with undefined 
behaviours - older code that is not, in fact, correct C code at all.

The way modern compilers handle this is to provide switches to give 
specific additional semantics that match certain behaviours of weaker 
tools that might be assumed by code - classic examples in gcc being 
"-fwrapv" to get wrapping integer overflow, and "-fno-strict-aliasing" 
to disable type-based alias analysis.  In addition, these take effect by 
default when the compiler is run, as optimisations are disabled unless 
explicitly enabled.

In other words, these compilers go out of their way to support incorrect 
(but reasonable at the time of writing) C code, and to support people 
who want the C language to be defined in a different way.  And yet 
people like you /still/ complain!

> 
>> There may be scope for changing certain /specific/ cases of undefined
>> behaviour in the standards into fully defined or implementation specific
>> behaviour.  But it would be for specific cases only, not as a
>> generalisation.
>>
> 
> The proposal is to change the default meaning of "undefined behavior" to
> "implementation specific" in all but a few clearly delineated cases.

That won't work.

First, /everything/ is undefined behaviour except in the cases where the 
C standards explicitly defines it.  You could turn some specific 
undefined behaviours into implementation defined behaviour, but you 
cannot possibly expect implementations to specify and document 
everything that is not written in the C standards.  If your cat sits on 
your keyboard, the behaviour is undefined by the C standards - do you 
really expect compiler vendors to pick a specific deterministic and 
documented behaviour for that event?

Secondly, undefined behaviour is a /good/ thing.  It is /better/ in many 
cases that things are undefined behaviour, rather than implementation 
defined behaviour.  I have explained above why I actively prefer integer 
overflow to be undefined behaviour.

Thirdly, in a great many cases of undefined behaviour as listed in Annex 
J.2 of the standard, there is no sensible choice of what implementation 
defined behaviour should be.

And even in cases where you apparently think there is an "obvious" 
choice for defining the behaviour, it often is not the case or not the 
only option.  For signed integer overflow, people might want two's 
complement wrapping.  But they might want saturation, or trapping, or 
optimisations based on ignoring the possibility of the overflow.


I invite you to read through J.2 of C11 or C18 (you have read the C 
standards that you criticise, and criticise compiler vendors for 
misreading, haven't you?) and list the implementation-defined behaviour 
you would like to see for your favourite cpu target.

> Of cause an implementation could define an insane implementation
> specific behavior, but it would stick out as a sore thumb to anyone
> reading the "implementation specific behavior" section of the 
> documentation, unlike a mostly undocumented obtuse interpretation.
> 
> 
> 
> Enjoy
> 
> Jakob

[toc] | [prev] | [standalone]

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

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

csiph-web