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 1 of 3  [1] 2 3  Next page →

#5990 — Addition of nocode keyword

I'd like to propose that the nocode keyword be added to standard
C.  It would convey that a block was intentionally left blank,
and was added only to allow program flow to move as it should in
certain cases.

    switch (value)
    {
        case 1:
        case 5:
        case 7:
        case 9:
            // All valid
            nocode;
            break;

        default:
            // Invalid
            report_error_message();
            return;
    }

It would be a way for the compiler to know that empty code blocks
were intentional, and a new diagnostic could be created to emit
when the compiler detect empty code blocks when use of nocode is
available.

It would also aid in documentation and code validation to know
that an empty block was empty intentionally, and not simply left
un-coded by accident / mistake.

-- 
Rick C. Hodgin

[toc] | [next] | [standalone]

#5991

Am 25.10.19 um 14:26 schrieb Rick C. Hodgin:
> I'd like to propose that the nocode keyword be added to standard
> C.  […]

I don't think adding a keyword to silence warnings has a chance of being
accepted. Try with an attribute instead.

Philipp

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

#5992

On Friday, October 25, 2019 at 9:53:05 AM UTC-4, Philipp Klaus Krause wrote:
> Am 25.10.19 um 14:26 schrieb Rick C. Hodgin:
> > I'd like to propose that the nocode keyword be added to standard
> > C.  […]
> 
> I don't think adding a keyword to silence warnings has a chance of being
> accepted. Try with an attribute instead.


It introduces a new opportunity to issue diagnostics by giving
the developer positive control over empty code blocks, whereas
today it's an unknown relegated to parsing comments in a best
case, or examining the logic in a worst case to see if it is
actually doing what it should.

With nocode, that uncertainty is replaced with certainty.

It's a good addition.

-- 
Rick C. Hodgin

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

#6140

Am 25.10.19 um 16:26 schrieb Rick C. Hodgin:
> On Friday, October 25, 2019 at 9:53:05 AM UTC-4, Philipp Klaus Krause wrote:
>> Am 25.10.19 um 14:26 schrieb Rick C. Hodgin:
>>> I'd like to propose that the nocode keyword be added to standard
>>> C.  […]
>>
>> I don't think adding a keyword to silence warnings has a chance of being
>> accepted. Try with an attribute instead.
> 
> 
> It introduces a new opportunity to issue diagnostics by giving
> the developer positive control over empty code blocks, whereas
> today it's an unknown relegated to parsing comments in a best
> case, or examining the logic in a worst case to see if it is
> actually doing what it should.
> 
> With nocode, that uncertainty is replaced with certainty.
> 
> It's a good addition.
> 

No, it is not. I doesn't change the semantics. Such stuff is exactly
what attributes were introduced for (so adding keywords would not be
necessary). Compare e.g. the fallthrough attribute.

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

#5993

On Friday, October 25, 2019 at 8:26:36 AM UTC-4, Rick C. Hodgin wrote:
> I'd like to propose that the nocode keyword be added to standard
> C.  It would convey that a block was intentionally left blank,
> and was added only to allow program flow to move as it should in
> certain cases.
> 
>     switch (value)
>     {
>         case 1:
>         case 5:
>         case 7:
>         case 9:
>             // All valid
>             nocode;
>             break;
> 
>         default:
>             // Invalid
>             report_error_message();
>             return;
>     }
> 
> It would be a way for the compiler to know that empty code blocks
> were intentional, and a new diagnostic could be created to emit
> when the compiler detect empty code blocks when use of nocode is
> available.
> 
> It would also aid in documentation and code validation to know
> that an empty block was empty intentionally, and not simply left
> un-coded by accident / mistake.


I need some help please.

Could someone give me some advice on where else to look in the C
standard, and how I should edit / extend / completely redo what
I've begun here?

----[ noode_proposal.txt ]-----
C ????:  nocode keyword

Submitter:  Rick C. Hodgin
Submission Date:  October 25, 2019


Summary:

nocode keyword to be added, to be used in code blocks which reflect
flow through program logic, but indicate no other code is required.


Justification:

In source code today, code blocks without code do not indicate in
C syntax whether or not that was the intention.  A developer must
seek out comments if present and try and understand the developer
notes for what's going on.  When comments are not present, a more
complex task of examining program logic flow must be made to then
know if the block should be empty or not.

Adding the nocode keyword would enable the developer to know with
certainty that an empty block was purposefully left empty, and
was not a mistake or omission of intended code that was simply
forgotten / overlooked.  It would also give the compiler the new
ability to generate diagnostics on empty code blocks when nocode
is missing.


Proposed changes (vs. the standard draft N2310):

Section 6.4.1 Keywords -- Add "nocode" into the list.

Section 6.8 Statements and blocks -- Add 6.8.7 nocode
statements.

    1 A empty statement placeholder may exist within any block,
      and must include the nocode keyword otherwise a diagnostic
      will be generated (See 7.2.1.2).

    2 Use of nocode can coexist with the flow control directives
      goto, continue, and break.

    3 Example:

      if (x) {
             nocode;
      } else {
             // Other code here
      }

      switch (x)
      {
        case 1:
        case 5:
        case 7:
        case 9:
             nocode;
             break;
        default:
             // Other code here
             break;
      }

Section 6.5 Expression -- Add:

    9 Use of the nocode keyword in any expression will evaluate
      as true.

      Example:

      for (x = 0; nocode; ++x)
      {
             // Code here
      }

      do {

      } while (nocode);

Section 7.2.1 Program Diagnostics -- Add section 7.2.1.2 "The
nocode keyword" with the following explanation:

    1 Synopsis:

        switch (x)
        {
          case 1:
          case 5:
            nocode;
            break;

          default:
            // Other code here
            break;
        }

    2 The nocode keyword signifies formally that the sur-
      rounding code block does not require any source code.

      If any non-flow-control statements are present in a
      block where nocode is used, a diagnostic will be gen-
      erated.

      If any empty blocks are found without the nocode key-
      word being present, a diagnostic will be generated.

    3 The nocode keyword has no impact on generated code.
      It is a mechanism for the developer and compiler used
      to identify cases where no other code should exist in
      the encapsulating block.
-----[ End ]-----

-- 
Rick C. Hodgin

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

#5994

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

> I'd like to propose that the nocode keyword be added to standard
> C.  It would convey that a block was intentionally left blank,
> and was added only to allow program flow to move as it should in
> certain cases.
>
>     switch (value)
>     {
>         case 1:
>         case 5:
>         case 7:
>         case 9:
>             // All valid
>             nocode;
>             break;
>
>         default:
>             // Invalid
>             report_error_message();
>             return;
>     }
>
> It would be a way for the compiler to know that empty code blocks
> were intentional, and a new diagnostic could be created to emit
> when the compiler detect empty code blocks when use of nocode is
> available.

C already has several ways to write an empty code block.  It also has an
empty statement.  All of these are human-language agnostic ways to do
the same thing as "nocode".

> It would also aid in documentation and code validation to know
> that an empty block was empty intentionally, and not simply left
> un-coded by accident / mistake.

-- 
Ben.

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

#5997

On 10/25/2019 6:42 PM, Ben Bacarisse wrote:
> C already ... has an empty statement.  All of these are human-
> language agnostic ways to do the same thing as "nocode".

I'm not aware of them.  Can you teach me?

In C today, how would you deterministically identify or signify
that this block of code's logic test was intentionally left empty?

     for (x = 0; ; ++x)
     {
         // Code here
     }

Or this one:

     for (i = 0; ; )
     {
     }

How do you know the empty portions weren't left out by mistake?
Without nocode or something like it, there's no way for the com-
piler to know.  There's no way for another developer to know
either without something like this:

     for (x = 0; /*no test here*/; ++x)
     {
         // Code here
     }

But what if in this online world we get some code from some
foreign language?  Rely on Google Translate to convey what it
means?

     for (x = 0; /*لا يوجد اختبار هنا*/; ++x)
     {
         // Code here
     }

There's no way to know with certainty, and that's the issue.  It
is a simple addition.  It generates no new code.  It provides
potentially very useful information.  And it solidifies and clar-
ifies code, something modern compiler efforts have sought to do
with great vehemence, preventing "const char assignments" from
being passed to char * functions, for example.

So much belt tightening in our code bases moving forward.  The
time for nocode is here.

>> It would also aid in documentation and code validation to know
>> that an empty block was empty intentionally, and not simply left
>> un-coded by accident / mistake.


-- 
Rick C. Hodgin

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

#6001

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

> On 10/25/2019 6:42 PM, Ben Bacarisse wrote:
>> C already ... has an empty statement.  All of these are human-
>> language agnostic ways to do the same thing as "nocode".
>
> I'm not aware of them.  Can you teach me?

I am sure you know them; I must have simply not have been clear.

The expression in an expression statement is optional, as are the
contents of a compound statement, so

  ;
  {}
  {;}
  {;;}

and so on (with optional comments) are all increasing insistent ways of
saying that no code was really, really what was intended.

> In C today, how would you deterministically identify or signify
> that this block of code's logic test was intentionally left empty?
>
>     for (x = 0; ; ++x)
>     {
>         // Code here
>     }

I don't understand the question.  The best way to show intent to a
reader (when it really is in doubt) is with a comment, and the best was
to show intent to a compiler is by writing code with the intended
meaning.  Maybe I don't know what "deterministically identify" means.

If you are talking about giving permission for a compiler to issue a
warning for the above then it already has it.  It could, perfectly
legally, say something like "Did you intend to leave the condition
empty?  To silence this warning, write an explicitly always true
expression.".

> Or this one:
>
>     for (i = 0; ; )
>     {
>     }
>
> How do you know the empty portions weren't left out by mistake?

The surest way for me to know is to understand the code.  Have you come
across an example where such a thing is an accident and yet it's not
obviously wrong?  I feel (without evidence) that any code like that will
be bad code for all sorts of other, more significant, reasons so I'd
like to see an example.

> Without nocode or something like it, there's no way for the com-
> piler to know.

See above.  The compiler can be suspicious about anything it likes and
can warn the programmer along with offering advice about what will make
it (the compiler) shut up.  You could even document a special meaning
for an option: -Waccidentally-empty that turns on these warnings while at
the same time behaving like -Dnocode.  You could then write

  for (i = 0; nocode; nocode) nocode;

a get no warnings even when compiled with -Waccidentally-empty.

> There's no way for another developer to know
> either without something like this:
>
>     for (x = 0; /*no test here*/; ++x)
>     {
>         // Code here
>     }

I would hope there is!  Do you have an actual example where it is not
obvious that the empty test was intended?  If you do, at the very least,
the code needs a comment which probably should explain more than your
example comment does.

> But what if in this online world we get some code from some
> foreign language?  Rely on Google Translate to convey what it
> means?
>
>     for (x = 0; /*لا يوجد اختبار هنا*/; ++x)
>     {
>         // Code here
>     }
>
> There's no way to know with certainty, and that's the issue.

Unless you are proposing a breaking change by /insisting/ on something
compiler-checkable, then I don't see how your suggestion helps for code
written by anyone else.  Other people will always be able to write the
form you obect to, and they can currently write explicit always-true
expressions and explicitly empty code (of any degree of complexity) if
they feel the intent is not clear.  And if they don't think they need to
make themselves extra clear, they probably won't use any new keywords
either.

-- 
Ben.

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

#6002

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> ... The best way to show intent to a
> reader (when it really is in doubt) is with a comment, and the best was
s/was/way/
> to show intent to a compiler is by writing code with the intended
> meaning.

I don't usually correct my already-posted typos (when I see them), but
this one is open to more misinterpretation than many.

-- 
Ben.

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

#6003

On Saturday, October 26, 2019 at 5:52:09 PM UTC-4, Ben Bacarisse wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> 
> > On 10/25/2019 6:42 PM, Ben Bacarisse wrote:
> >> C already ... has an empty statement.  All of these are human-
> >> language agnostic ways to do the same thing as "nocode".
> >
> > I'm not aware of them.  Can you teach me?
> 
> I am sure you know them; I must have simply not have been clear.
> 
> The expression in an expression statement is optional, as are the
> contents of a compound statement, so
> 
>   ;
>   {}
>   {;}
>   {;;}
> 
> and so on (with optional comments) are all increasing insistent ways of
> saying that no code was really, really what was intended.


Understood.  Thank you.

-- 
Rick C. Hodgin

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

#5995

On 10/25/19 9:26 AM, Rick C. Hodgin wrote:
> I'd like to propose that the nocode keyword be added to standard
> C.  It would convey that a block was intentionally left blank,
> and was added only to allow program flow to move as it should in
> certain cases.
> 
>     switch (value)
>     {
>         case 1:
>         case 5:
>         case 7:
>         case 9:
>             // All valid
>             nocode;
>             break;
> 
>         default:
>             // Invalid
>             report_error_message();
>             return;
>     }
> 
> It would be a way for the compiler to know that empty code blocks
> were intentional, and a new diagnostic could be created to emit
> when the compiler detect empty code blocks when use of nocode is
> available.
> 
> It would also aid in documentation and code validation to know
> that an empty block was empty intentionally, and not simply left
> un-coded by accident / mistake.
> 

If the idea is that now an empty block without nocode requires a
diagnostic, then this is a non-starter as it will break too much
existing code (any code that currently has an empty block)

If this is to define that the compiler will now generate a new class of
'diagnostic' (at least by the standard) that is a warning, I think again
that is a non-started as the Standard has no concept of required
warnings, ALL required diagnostics (as far as I know) allow the
implementation to fail to translate the code, and if it does, the
results are undefined, so in effect, they are errors or notifications
that an extension has been used.

A fall throught attribute was defined (though that might have been in
C++) to suppress a common warning, which I suppose is what you might be
modling the idea on, but a LOT of implementations warn on possibly
unintended switch fall through, but I am not sure if any warn about
empty statements by default, so you have a higher bar to pass to get
something like this in. It is also, in my opinion a much rarer form of
error. Since many other languages do 'automatic breaks' in their
equivalent of switch statements, it missing isn't that obvious.
Forgetting to put the actual code to do what you want in that case seems
much harder (unless you are just slapping together some crude framework,
but even then you should be adding the TODO comments to point to what is
missing.

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

#5996

On Friday, October 25, 2019 at 9:10:13 PM UTC-4, Richard Damon wrote:
> If the idea is that now an empty block without nocode requires a
> diagnostic, then this is a non-starter as it will break too much
> existing code (any code that currently has an empty block)

I would assume it would roll out in stages, but I think it should
be defined that way in the standard.  It would not be an issued
diagnostic in the first stage, unless an option was turned on to
enable it.  It would be a warning-level diagnostic in a later re-
lease, and then finally an error in a future one.  It would give
people time to update their code.

> If this is to define that the compiler will now generate a new class of
> 'diagnostic' (at least by the standard) that is a warning, I think again
> that is a non-started as the Standard has no concept of required
> warnings, ALL required diagnostics (as far as I know) allow the
> implementation to fail to translate the code, and if it does, the
> results are undefined, so in effect, they are errors or notifications
> that an extension has been used.

The diagnostic severity would be up to the compiler authors and
implementers.

The root purpose is two-fold actually:  documentation, and the re-
moval of code ambiguity.

> A fall throught attribute was defined (though that might have been in
> C++) to suppress a common warning, which I suppose is what you might be
> modling the idea on, but a LOT of implementations warn on possibly
> unintended switch fall through, but I am not sure if any warn about
> empty statements by default, so you have a higher bar to pass to get
> something like this in. It is also, in my opinion a much rarer form of
> error. Since many other languages do 'automatic breaks' in their
> equivalent of switch statements, it missing isn't that obvious.
> Forgetting to put the actual code to do what you want in that case seems
> much harder (unless you are just slapping together some crude framework,
> but even then you should be adding the TODO comments to point to what is
> missing.

My position is the language needs the deterministic ability to
identify intentionally empty code blocks, and non-intentionally
empty code blocks.  Without that ability, it leaves a big question
in cases where an empty block is encountered, which, as you state,
is likely in a lot of code.

-- 
Rick C. Hodgin

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

#6011

On 10/25/19 10:02 PM, Rick C. Hodgin wrote:
> On Friday, October 25, 2019 at 9:10:13 PM UTC-4, Richard Damon wrote:
>> If the idea is that now an empty block without nocode requires a
>> diagnostic, then this is a non-starter as it will break too much
>> existing code (any code that currently has an empty block)
> 
> I would assume it would roll out in stages, but I think it should
> be defined that way in the standard.  It would not be an issued
> diagnostic in the first stage, unless an option was turned on to
> enable it.  It would be a warning-level diagnostic in a later re-
> lease, and then finally an error in a future one.  It would give
> people time to update their code.

To the Standard, there is no such thing as a 'Warning Level Diagnostic'.
All required diagnostics result in the program's behavior being
undefined, (if a program is created) so are effectively 'errors', but an
implementation is able to define the behavior and thus provide an
extension. To add the concept of a Warning to the standard would be a
major change and significant work.

Because it breaks valid programs using what can be a useful feature, it
also has a very high hurdle to pass to show it add something of great
value, which I don't see. I will say that personally, this isn't the
sort of error I see being done often.

> 
>> If this is to define that the compiler will now generate a new class of
>> 'diagnostic' (at least by the standard) that is a warning, I think again
>> that is a non-started as the Standard has no concept of required
>> warnings, ALL required diagnostics (as far as I know) allow the
>> implementation to fail to translate the code, and if it does, the
>> results are undefined, so in effect, they are errors or notifications
>> that an extension has been used.
> 
> The diagnostic severity would be up to the compiler authors and
> implementers.
> 
> The root purpose is two-fold actually:  documentation, and the re-
> moval of code ambiguity.

This sounds like an ideal sort of thing for a compiler to implement as
an extension (almost doesn't need to be an real extension if you spell
the keyword as something like // nocode or /* nocode */ like gcc does
with // nobreak since a comment is a perfectly fine to have with an
empty statement.
> 
>> A fall throught attribute was defined (though that might have been in
>> C++) to suppress a common warning, which I suppose is what you might be
>> modling the idea on, but a LOT of implementations warn on possibly
>> unintended switch fall through, but I am not sure if any warn about
>> empty statements by default, so you have a higher bar to pass to get
>> something like this in. It is also, in my opinion a much rarer form of
>> error. Since many other languages do 'automatic breaks' in their
>> equivalent of switch statements, it missing isn't that obvious.
>> Forgetting to put the actual code to do what you want in that case seems
>> much harder (unless you are just slapping together some crude framework,
>> but even then you should be adding the TODO comments to point to what is
>> missing.
> 
> My position is the language needs the deterministic ability to
> identify intentionally empty code blocks, and non-intentionally
> empty code blocks.  Without that ability, it leaves a big question
> in cases where an empty block is encountered, which, as you state,
> is likely in a lot of code.
> 

WHY is this an ambiguity that is any different than any other case of
did the programmer right what the meant or not?

THere is nothing in the language that makes an empty code block
'ambiguous', its meaning is very clear.

If anything like this would make sense adding, it would be making
spacing significant to make something like:

  if(x < y)
    x = x + 1;
    y = y + 1;
  some other code

Here, the line y = y + 1 is indented like it is supposed to be
controlled by the if, but since it isn't inside a compond statement, it
isn't. This is something that some implementatios will warn about, and
it could be argued that it is bad enough style that it is worth making
it illegal, but I really doubt that will happen.


As an aside, I will remind you that you have commented that you find
Standard impossible to read and understand.  That condition probably
makes you a poor choice

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

#6014

On 10/28/2019 11:45 PM, Richard Damon wrote:
> On 10/25/19 10:02 PM, Rick C. Hodgin wrote:
>> On Friday, October 25, 2019 at 9:10:13 PM UTC-4, Richard Damon wrote:
>>> If the idea is that now an empty block without nocode requires a
>>> diagnostic, then this is a non-starter as it will break too much
>>> existing code (any code that currently has an empty block)
>>
>> I would assume it would roll out in stages, but I think it should
>> be defined that way in the standard.  It would not be an issued
>> diagnostic in the first stage, unless an option was turned on to
>> enable it.  It would be a warning-level diagnostic in a later re-
>> lease, and then finally an error in a future one.  It would give
>> people time to update their code.
> 
> To the Standard, there is no such thing as a 'Warning Level Diagnostic'.

Section 5.1.22 of N2310, page 23 in the draft I have (page 10 in
the written numbers on the page), acknowledges that real-world
implementations of the C Standard applied to an actual app, do
have warnings:

     9)  An implementation is encourage to identify the nature of, and
         where possible localize, each violation.  Of course, an imple-
         mentation is free to produce any number of diagnostic messages,
         often referred to as warnings, as long as a valid program is
         still correctly translated.  It can also successfully translate
         an invalid program.  Annex I lists a few of the more common
         warnings.

And then in Annex I, page 418 in the draft I have (page 405 in the
written numbers on the page), it states:

     1)  An implementation may genreate warnings in many situations,
         none of which are specified as part of this document.  The
         following are a few of the more common situations.

So there is an acknowledgement that warnings exist, and are even to
be expected.  They're just not formally defined.

> All required diagnostics result in the program's behavior being
> undefined, (if a program is created) so are effectively 'errors', but an
> implementation is able to define the behavior and thus provide an
> extension. To add the concept of a Warning to the standard would be a
> major change and significant work.
> 
> Because it breaks valid programs using what can be a useful feature, it
> also has a very high hurdle to pass to show it add something of great
> value, which I don't see. I will say that personally, this isn't the
> sort of error I see being done often.

We have:
     void function_name(void);

Why not just this:
     function_name;

There's a reason to include an explicit conveyance of the non-exist-
ence of something.  Zero is one of the most powerful number concepts
we have.

>>> If this is to define that the compiler will now generate a new class of
>>> 'diagnostic' (at least by the standard) that is a warning, I think again
>>> that is a non-started as the Standard has no concept of required
>>> warnings, ALL required diagnostics (as far as I know) allow the
>>> implementation to fail to translate the code, and if it does, the
>>> results are undefined, so in effect, they are errors or notifications
>>> that an extension has been used.
>>
>> The diagnostic severity would be up to the compiler authors and
>> implementers.
>>
>> The root purpose is two-fold actually:  documentation, and the re-
>> moval of code ambiguity.
> 
> This sounds like an ideal sort of thing for a compiler to implement as
> an extension (almost doesn't need to be an real extension if you spell
> the keyword as something like // nocode or /* nocode */ like gcc does
> with // nobreak since a comment is a perfectly fine to have with an
> empty statement.

It can be implemented today:

     #define nocode

And then used wherever.  But it won't generate diagnostics, and that's
the biggest part of the equation that's missing without having direct
compiler-specified support.

>>> A fall throught attribute was defined (though that might have been in
>>> C++) to suppress a common warning, which I suppose is what you might be
>>> modling the idea on, but a LOT of implementations warn on possibly
>>> unintended switch fall through, but I am not sure if any warn about
>>> empty statements by default, so you have a higher bar to pass to get
>>> something like this in. It is also, in my opinion a much rarer form of
>>> error. Since many other languages do 'automatic breaks' in their
>>> equivalent of switch statements, it missing isn't that obvious.
>>> Forgetting to put the actual code to do what you want in that case seems
>>> much harder (unless you are just slapping together some crude framework,
>>> but even then you should be adding the TODO comments to point to what is
>>> missing.
>>
>> My position is the language needs the deterministic ability to
>> identify intentionally empty code blocks, and non-intentionally
>> empty code blocks.  Without that ability, it leaves a big question
>> in cases where an empty block is encountered, which, as you state,
>> is likely in a lot of code.
> 
> WHY is this an ambiguity that is any different than any other case of
> did the programmer right what the meant or not?

I think all cases of ambiguity should be addressed.

> THere is nothing in the language that makes an empty code block
> 'ambiguous', its meaning is very clear.

It is clear to the compiler, but it leaves the open question:  was
the intention to not have code there?  Or was it simply forgotten?

We need the ability to know explicitly.

> If anything like this would make sense adding, it would be making
> spacing significant to make something like:
> 
>    if(x < y)
>      x = x + 1;
>      y = y + 1;
>    some other code

I agree that there should be an option to enforce a defined type of
syntax spacing, but we would not agree on what it is.  IIRC, ANSI
uses 4-wide spacing for tabs.  GNU uses 8.  Some have braces indent-
ed, others don't.  I block off sections of code with meaning:

------
     code_above();       // Followed by a triple-space


     //////////
     // Explanation here
     //////
         // Comments for each related sub-block
         indented_code_here();
         relating_to_the_explanation();

         // Double-spaced comments go here
         and_more_code();
         goes_here();    // Followed by a triple-space


     // New comments for the next sub-block that doesn't need an
     // outer encapsulating block
     code_continues_here();
------

I do that primarily to address my dyslexia, so that a different
part of my brain categorizes code so I'm not constantly reading
only to understand things.

> Here, the line y = y + 1 is indented like it is supposed to be
> controlled by the if, but since it isn't inside a compond statement, it
> isn't. This is something that some implementatios will warn about, and
> it could be argued that it is bad enough style that it is worth making
> it illegal, but I really doubt that will happen.

If the spacing parameters could be all programmable, as many IDEs add
those features to allow custom formatting of source code, then I would
agree.  The compiler could use those rules and ensure that the code
was not only syntactically correct, but also contained proper spacing
by its own standard.

> As an aside, I will remind you that you have commented that you find
> Standard impossible to read and understand.  That condition probably
> makes you a poor choice

Only because of my dyslexia.  If someone would sit down with me and
explain it to me in speech, where I could interact a bit and ask
questions, it would not be an issue.  It's just worse than reading
stereo instructions in its present form.  I do not comprehend things
well written like that.  It's like a jumbled mass of confusion to me
when I read it.  It's actually very difficult for me to read normal
text as well, like these posts here on Usenet.  I have to really
really concentrate, and it wears me out if I do too much of it.

-- 
Rick C. Hodgin

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

#6015

On 10/29/2019 8:15 AM, Rick C. Hodgin wrote:
> I agree that there should be an option to enforce a defined type of
> syntax spacing, but we would not agree on what it is.  IIRC, ANSI
> uses 4-wide spacing for tabs.  GNU uses 8.  Some have braces indent-
> ed, others don't.  I block off sections of code with meaning:
> 
> ------
>      code_above();       // Followed by a triple-space
> 
> 
>      //////////
>      // Explanation here
>      //////
>          // Comments for each related sub-block
>          indented_code_here();
>          relating_to_the_explanation();
> 
>          // Double-spaced comments go here
>          and_more_code();
>          goes_here();    // Followed by a triple-space
> 
> 
>      // New comments for the next sub-block that doesn't need an
>      // outer encapsulating block
>      code_continues_here();
> ------
> 
> I do that primarily to address my dyslexia, so that a different
> part of my brain categorizes code so I'm not constantly reading
> only to understand things.

This need to indent is so prevalent in my ability to easily read and
maintain even my own code, that I added a new language feature to
CAlive.  They are the ||| and |||| operators.

||| serves as an "ignore me" operator.  It serves no purpose, except
to be part of a notable visualization presentation designed to catch
the eye.

|||| is a line comment.  They're used together in code like this:

------
     code_above();       // Followed by a double-space

   ||||||||||
   |||| Explanation here
   |||| Maybe even a multi-line explanation
   ||||||
   ||||
   |||   // Comments for each related sub-block
   |||   indented_code_here();
   |||   relating_to_the_explanation();
   |||
   |||   // Double-spaced comments go here
   |||   and_more_code();
   |||   goes_here();    // Followed by a double-space
   ||||
   ||||||

     // New comments for the next sub-block that doesn't need an
     // outer encapsulating block
     code_continues_here();
------

It allows the block to be visually identified easily in source
code.  All code within the block relates to it.  It can be
collapsed with the explanation portion remaining so you know
what that block of code actually did as by description.  It
also introduces a new ability within the debugger, to single-
step through code by those blocks.  And with the use of an IDE,
starts and stops for each block can be flagged, and it does the
manual labor of typing in the |||| and ||| for you as needed.
You just type code like normal.

And in the IDE, the presentation can be different.  Rather
than showing ||| characters everywhere which can be cluttered
to some people, it can be made into a vertical line, or enclosed
in a rectangle, or have the background color changed, or a fade-
in color from the left to the right to mark it off subtly, but
still visually, or in other ways.

In any event ... I've tried with C.  There are several features
I desired to see added.  I'm relegated to adding them to my own
language.  And I'm okay with that.  It's the only way to have
real control over a thing anyway.

CAlive.  It will provide desirable advancements, and be THE way
to keep the C language alive in moving forward, unless they do
succumb and start implementing various of CAlive's features.

-- 
Rick C. Hodgin

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

#6027

On 10/29/19 8:15 AM, Rick C. Hodgin wrote:
> On 10/28/2019 11:45 PM, Richard Damon wrote:
>> On 10/25/19 10:02 PM, Rick C. Hodgin wrote:
>>> On Friday, October 25, 2019 at 9:10:13 PM UTC-4, Richard Damon wrote:
>>>> If the idea is that now an empty block without nocode requires a
>>>> diagnostic, then this is a non-starter as it will break too much
>>>> existing code (any code that currently has an empty block)
>>>
>>> I would assume it would roll out in stages, but I think it should
>>> be defined that way in the standard.  It would not be an issued
>>> diagnostic in the first stage, unless an option was turned on to
>>> enable it.  It would be a warning-level diagnostic in a later re-
>>> lease, and then finally an error in a future one.  It would give
>>> people time to update their code.
>>
>> To the Standard, there is no such thing as a 'Warning Level Diagnostic'.
> 
> Section 5.1.22 of N2310, page 23 in the draft I have (page 10 in
> the written numbers on the page), acknowledges that real-world
> implementations of the C Standard applied to an actual app, do
> have warnings:
> 
>     9)  An implementation is encourage to identify the nature of, and
>         where possible localize, each violation.  Of course, an imple-
>         mentation is free to produce any number of diagnostic messages,
>         often referred to as warnings, as long as a valid program is
>         still correctly translated.  It can also successfully translate
>         an invalid program.  Annex I lists a few of the more common
>         warnings.
> 
> And then in Annex I, page 418 in the draft I have (page 405 in the
> written numbers on the page), it states:
> 
>     1)  An implementation may genreate warnings in many situations,
>         none of which are specified as part of this document.  The
>         following are a few of the more common situations.
> 
> So there is an acknowledgement that warnings exist, and are even to
> be expected.  They're just not formally defined.

Yes, the Standard, in the non-normative footnotes/annexes acknowledges
that warnings exist. None of these are defined by the Standard, and the
Standard has no framework to officially define a required warning. The
Standard doesn't even that formally define a 'Error', as almost all
'Required Diagnostics' may still result in the generation of a program
(but whose behavior is undefined by the Standard, but might be defined
by the implementation). The only thing that MUST not generate a program
is the processing of a #error directive that isn't bypassed by a #if or
similar control.

The fallthrough attribute in C++ (which may come to Standard C) is the
closest example to what you are proposing, but that relates to a common
warning in many implementations, generated in response to a common
programming error, for a construct that actually is commonly used
properly too, so has a need for a standard way to being suppressed.

This nocode condition doesn't seem to be a common programming error, and
I don't hear many people complaining about getting warnings when
legitimately using that construct, so it doesn't meet the other parts of
the condition. To me, it seems to be a cute solution looking for a
problem to solve, but not finding one.
> 
>> All required diagnostics result in the program's behavior being
>> undefined, (if a program is created) so are effectively 'errors', but an
>> implementation is able to define the behavior and thus provide an
>> extension. To add the concept of a Warning to the standard would be a
>> major change and significant work.
>>
>> Because it breaks valid programs using what can be a useful feature, it
>> also has a very high hurdle to pass to show it add something of great
>> value, which I don't see. I will say that personally, this isn't the
>> sort of error I see being done often.
> 
> We have:
>     void function_name(void);
> 
> Why not just this:
>     function_name;
> 

Because that doesn't parse to the same meaning. without the voids it
means something different. Note that originally, the void return type
was not required, and the lack of a explicit return type caused the type
to be assumed to be int. It was decided that this assumed default caused
enough problems that it was decided that in that case, intentionally
breaking the old programs using that feature was desired.

The second void also has meaning. The declaration
    void function_name();
has a different meaning (mostly a throwback to older versions of the
language)

Omitting the () in the definition make it a very different sort of
declaration. While void x; doesn't make much sense, for other types like
int x; it has a very definite meaning, the declaring of a variable, so
it would require some form of mind-reading to decide if it somehow means
in some cases defining a function with no parameters vs a variable.

> There's a reason to include an explicit conveyance of the non-exist-
> ence of something.  Zero is one of the most powerful number concepts
> we have.
> 
>>>> If this is to define that the compiler will now generate a new class of
>>>> 'diagnostic' (at least by the standard) that is a warning, I think
>>>> again
>>>> that is a non-started as the Standard has no concept of required
>>>> warnings, ALL required diagnostics (as far as I know) allow the
>>>> implementation to fail to translate the code, and if it does, the
>>>> results are undefined, so in effect, they are errors or notifications
>>>> that an extension has been used.
>>>
>>> The diagnostic severity would be up to the compiler authors and
>>> implementers.
>>>
>>> The root purpose is two-fold actually:  documentation, and the re-
>>> moval of code ambiguity.
>>
>> This sounds like an ideal sort of thing for a compiler to implement as
>> an extension (almost doesn't need to be an real extension if you spell
>> the keyword as something like // nocode or /* nocode */ like gcc does
>> with // nobreak since a comment is a perfectly fine to have with an
>> empty statement.
> 
> It can be implemented today:
> 
>     #define nocode
> 
> And then used wherever.  But it won't generate diagnostics, and that's
> the biggest part of the equation that's missing without having direct
> compiler-specified support.
> 
>>>> A fall throught attribute was defined (though that might have been in
>>>> C++) to suppress a common warning, which I suppose is what you might be
>>>> modling the idea on, but a LOT of implementations warn on possibly
>>>> unintended switch fall through, but I am not sure if any warn about
>>>> empty statements by default, so you have a higher bar to pass to get
>>>> something like this in. It is also, in my opinion a much rarer form of
>>>> error. Since many other languages do 'automatic breaks' in their
>>>> equivalent of switch statements, it missing isn't that obvious.
>>>> Forgetting to put the actual code to do what you want in that case
>>>> seems
>>>> much harder (unless you are just slapping together some crude
>>>> framework,
>>>> but even then you should be adding the TODO comments to point to
>>>> what is
>>>> missing.
>>>
>>> My position is the language needs the deterministic ability to
>>> identify intentionally empty code blocks, and non-intentionally
>>> empty code blocks.  Without that ability, it leaves a big question
>>> in cases where an empty block is encountered, which, as you state,
>>> is likely in a lot of code.
>>
>> WHY is this an ambiguity that is any different than any other case of
>> did the programmer right what the meant or not?
> 
> I think all cases of ambiguity should be addressed.
> 
>> THere is nothing in the language that makes an empty code block
>> 'ambiguous', its meaning is very clear.
> 
> It is clear to the compiler, but it leaves the open question:  was
> the intention to not have code there?  Or was it simply forgotten?
> 
> We need the ability to know explicitly.
> 
>> If anything like this would make sense adding, it would be making
>> spacing significant to make something like:
>>
>>    if(x < y)
>>      x = x + 1;
>>      y = y + 1;
>>    some other code
> 
> I agree that there should be an option to enforce a defined type of
> syntax spacing, but we would not agree on what it is.  IIRC, ANSI
> uses 4-wide spacing for tabs.  GNU uses 8.  Some have braces indent-
> ed, others don't.  I block off sections of code with meaning:
> 
> ------
>     code_above();       // Followed by a triple-space
> 
> 
>     //////////
>     // Explanation here
>     //////
>         // Comments for each related sub-block
>         indented_code_here();
>         relating_to_the_explanation();
> 
>         // Double-spaced comments go here
>         and_more_code();
>         goes_here();    // Followed by a triple-space
> 
> 
>     // New comments for the next sub-block that doesn't need an
>     // outer encapsulating block
>     code_continues_here();
> ------
> 
> I do that primarily to address my dyslexia, so that a different
> part of my brain categorizes code so I'm not constantly reading
> only to understand things.
> 
>> Here, the line y = y + 1 is indented like it is supposed to be
>> controlled by the if, but since it isn't inside a compond statement, it
>> isn't. This is something that some implementatios will warn about, and
>> it could be argued that it is bad enough style that it is worth making
>> it illegal, but I really doubt that will happen.
> 
> If the spacing parameters could be all programmable, as many IDEs add
> those features to allow custom formatting of source code, then I would
> agree.  The compiler could use those rules and ensure that the code
> was not only syntactically correct, but also contained proper spacing
> by its own standard.
> 
>> As an aside, I will remind you that you have commented that you find
>> Standard impossible to read and understand.  That condition probably
>> makes you a poor choice
> 
> Only because of my dyslexia.  If someone would sit down with me and
> explain it to me in speech, where I could interact a bit and ask
> questions, it would not be an issue.  It's just worse than reading
> stereo instructions in its present form.  I do not comprehend things
> well written like that.  It's like a jumbled mass of confusion to me
> when I read it.  It's actually very difficult for me to read normal
> text as well, like these posts here on Usenet.  I have to really
> really concentrate, and it wears me out if I do too much of it.
> 

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

#6031

On Tuesday, October 29, 2019 at 10:37:55 PM UTC-4, Richard Damon wrote:
> On 10/29/19 8:15 AM, Rick C. Hodgin wrote:
> > On 10/28/2019 11:45 PM, Richard Damon wrote:
> >> On 10/25/19 10:02 PM, Rick C. Hodgin wrote:
> >>> On Friday, October 25, 2019 at 9:10:13 PM UTC-4, Richard Damon wrote:
> >>>> If the idea is that now an empty block without nocode requires a
> >>>> diagnostic, then this is a non-starter as it will break too much
> >>>> existing code (any code that currently has an empty block)
> >>>
> >>> I would assume it would roll out in stages, but I think it should
> >>> be defined that way in the standard.  It would not be an issued
> >>> diagnostic in the first stage, unless an option was turned on to
> >>> enable it.  It would be a warning-level diagnostic in a later re-
> >>> lease, and then finally an error in a future one.  It would give
> >>> people time to update their code.
> >>
> >> To the Standard, there is no such thing as a 'Warning Level Diagnostic'.
> > 
> > Section 5.1.22 of N2310, page 23 in the draft I have (page 10 in
> > the written numbers on the page), acknowledges that real-world
> > implementations of the C Standard applied to an actual app, do
> > have warnings:
> > 
> >     9)  An implementation is encourage to identify the nature of, and
> >         where possible localize, each violation.  Of course, an imple-
> >         mentation is free to produce any number of diagnostic messages,
> >         often referred to as warnings, as long as a valid program is
> >         still correctly translated.  It can also successfully translate
> >         an invalid program.  Annex I lists a few of the more common
> >         warnings.
> > 
> > And then in Annex I, page 418 in the draft I have (page 405 in the
> > written numbers on the page), it states:
> > 
> >     1)  An implementation may genreate warnings in many situations,
> >         none of which are specified as part of this document.  The
> >         following are a few of the more common situations.
> > 
> > So there is an acknowledgement that warnings exist, and are even to
> > be expected.  They're just not formally defined.
> 
> Yes, the Standard, in the non-normative footnotes/annexes acknowledges
> that warnings exist. None of these are defined by the Standard, and the
> Standard has no framework to officially define a required warning.

I'm well beyond the point of caring on this issue, and indeed any-
thing related to the betterment of C.

> The fallthrough attribute in C++ (which may come to Standard C) is the
> closest example to what you are proposing, but that relates to a common
> warning in many implementations, generated in response to a common
> programming error, for a construct that actually is commonly used
> properly too, so has a need for a standard way to being suppressed.

C seems to be reactionary to what exists, not proactive as by a
guiding philosophy.  I think that's why I take exception to its
various facets and implementation, because there are some things
that need to be added IMO.  Why C hasn't introduced the basic and
simple class, for example, is beyond me.  That one facet alone
would take so much C++ code away from C++ because many people do
not want C++'s complexity, but use it because it supports classes.

Other features are like that too ... but who cares, right?  Cer-
tainly not I.

> This nocode condition doesn't seem to be a common programming error, and
> I don't hear many people complaining about getting warnings when
> legitimately using that construct, so it doesn't meet the other parts of
> the condition. To me, it seems to be a cute solution looking for a
> problem to solve, but not finding one.
> > 
> >> All required diagnostics result in the program's behavior being
> >> undefined, (if a program is created) so are effectively 'errors', but an
> >> implementation is able to define the behavior and thus provide an
> >> extension. To add the concept of a Warning to the standard would be a
> >> major change and significant work.
> >>
> >> Because it breaks valid programs using what can be a useful feature, it
> >> also has a very high hurdle to pass to show it add something of great
> >> value, which I don't see. I will say that personally, this isn't the
> >> sort of error I see being done often.
> > 
> > We have:
> >     void function_name(void);
> > 
> > Why not just this:
> >     function_name;
> 
> Because that doesn't parse to the same meaning.

If you re-designed your parser it could.

> Omitting the () in the definition make it a very different sort of
> declaration.

That a typo.  I intended to write:

    function_name();

When function_name had not yet been defined, referencing it
like that could assume void function_name(void).  And I do
recognize that there's a default int type assumed, which I
also think is ridiculous.  If you're going to have a strongly
typed language, you should also have a strongly declared lan-
guage.

This is my last post on the matter.  I don't care about C any
longer.  There's only so much a man can take before he steps
away and leaves the thing he's in pursuit of for something
more under his control / ability to influence.

I've spent the last year taking steps to move my life in a
direction that will give me that control.  We'll see what
fruit it bears.

-- 
Rick C. Hodgin

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

#5999

Am 26.10.19 um 03:10 schrieb Richard Damon:
> A fall throught attribute was defined (though that might have been in
> C++)

It has been proposed to C, too. It was to be voted on yesterday
(http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2437.htm). I don't
know the result yet.

Philipp

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

#6005

On 25/10/2019 14:26, Rick C. Hodgin wrote:
> I'd like to propose that the nocode keyword be added to standard
> C.  It would convey that a block was intentionally left blank,
> and was added only to allow program flow to move as it should in
> certain cases.
> 
>      switch (value)
>      {
>          case 1:
>          case 5:
>          case 7:
>          case 9:
>              // All valid
>              nocode;
>              break;
> 
>          default:
>              // Invalid
>              report_error_message();
>              return;
>      }
> 
> It would be a way for the compiler to know that empty code blocks
> were intentional, and a new diagnostic could be created to emit
> when the compiler detect empty code blocks when use of nocode is
> available.
> 
> It would also aid in documentation and code validation to know
> that an empty block was empty intentionally, and not simply left
> un-coded by accident / mistake.
> 

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");

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

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



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]

#6009

On Monday, October 28, 2019 at 5:42:19 AM UTC-4, Jakob Bohm wrote:
> On 25/10/2019 14:26, Rick C. Hodgin wrote:
> > It would be a way for the compiler to know that empty code blocks
> > were intentional, and a new diagnostic could be created to emit
> > when the compiler detect empty code blocks when use of nocode is
> > available.
> > 
> > It would also aid in documentation and code validation to know
> > that an empty block was empty intentionally, and not simply left
> > un-coded by accident / mistake.
> 
> 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");
> 
> In general, it would be useful to supplement the C standard with some 
> statements of best practice for implementations, such as:
> 
>   * 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.
>   * 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).
>   * 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.


I agree on all points.

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.

-- 
Rick C. Hodgin

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web