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

Groups > comp.std.c > #6027

Re: Addition of nocode keyword

Show all headers | View raw

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

Back to comp.std.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web