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

Groups > comp.lang.c > #71953

Re: Spurious diagnostic messages

Show all headers | View raw

On 05/10/15 09:14, Tim Rentsch wrote:
> David Brown <david.brown@hesbynett.no> writes:
> 
>> On 29/09/15 17:55, Tim Rentsch wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>
>>>> On 24/08/15 18:58, Tim Rentsch wrote:
>>>>
>>>>> [snipping almost everything as there is only one point
>>>>>   I am responding to.]
>>>>
>>>> binary literals are solidly established in compliers and
>>>> we can use them when we find them helpful regardless of the C
>>>> standards.
>>>
>>> And I have no problem with that.  If a group or subcommunity
>>> thinks a particular extension is useful and wants to use it
>>> for their own development, I wouldn't try to stop them.  But
>>> that isn't in and of itself a compelling argument to change
>>> the ISO C standard.
>>
>> With C11, the C standard introduced the idea of optional features.
>> That I think should lower the bar to adding new features to C - it
>> means that a feature can be added to the standard without requiring
>> compilers to implement it.
> 
> The downside of optional features is that they tend to fragment
> the language and they may die from neglect due to self-fulfilling
> prophecy.  I understand why some parts of C99 were make optional
> in C11, but IMO such a step should be taken only very sparingly.

I agree that optional features can lead to fragmentation.  But an even
faster path to fragmentation is when the C standards ignore features
that are implemented by a number of compilers, and used by at least a
proportion of developers.  This is the case with 0b binary literals.  It
is an example of a feature that has already fragmented the C compiler
community.  Standardising them as an optional feature would take control
of that fragmentation.  (Remember, with 0b binary literals, we are not
talking about a new feature under consideration - it is a feature that
exists already and is in common use in the most widely used C compilers.)

> 
>> This thread has been going on for a while, but if I may try to sum up:
>>
>> On the one side, we have:
>>
>> 0b binary literals are a common extension that are implemented on a
>> number of compilers.  On those compilers, making it part of the
>> standard is almost zero cost.
>>
>> 0b binary literals are a useful feature, and many embedded developers
>> take advantage of them where they exist.
>>
>> 0b binary literals are part of the current C++ standards.
>>
>> 0b binary literals do not conflict with existing C standards in any way.
>>
>> On the other side, we have:
>>
>> Binary literals are not essential - it is possible to use hex literals
>> or macros (albeit somewhat ugly and complicated) to make binary
>> constants.
>>
>> Binary literals are not used very much, even by embedded programmers.
>>
>> Binary literals are of very little potential use to C programmers
>> other than embedded programmers (though embedded programming is an
>> increasing proportion of C usage).
>>
>> Am I missing anything?
> 
> Yes, I would say the key point I've been trying to make all along is
> that the onus of presenting a convincing rationale rests on those
> who are advocating the new feature.  I don't mind being convinced
> that binary constants are a worthwhile addition, but the basis for
> such a rationale should be more than just statements of opinion.

You keep repeating that.  As Ian has said, you appear to be asking for a
level of evidence that is way beyond something that can be realistically
presented (and certainly not something that can be given in a
newsgroup), and that is well beyond the evidence that has been required
in the past to justify far more significant and intrusive changes to the
C language.

Developers wanted 0b binary literals.  Compiler developers implemented
them.  Developers use them.  Embedded developers are happy with them
from a practical viewpoint, but those of us who feel the standards are
important and who want to avoid fragmentation would like them to be
codified in the standards.  This is all fact, not opinion.  No one has
given you numbers here, because no one knows any good numbers to give
you - thus judgements about how many people benefit from binary
literals, and how useful they are, are opinion.

It's that simple.  You will get no more evidence than this.  If you
really want a detailed cost-benefit analysis based on statistics of
hours saved or bugs prevented in a fair comparison between C with binary
literals and C without binary literals, you will need to conduct the
research yourself.  No one else is going to spend the millions needed to
achieve this in a statistically valid manner - just as no one has spend
the millions needed to get similar evidence before introducing VLAs or
removing implicit ints.


You set the bar too high here.  And if your requirements match the
attitude of the C standards committee, then they too set the bar too
high - and they will sit in their ivory tower, watching as C becomes
more fragmented and less and less relevant as a programming language.


> 
>> I believe that C should adopt them in future standards - I believe
>> the C standards need to keep abreast with real-world usage,
>> especially in the increasingly important embedded area, or they
>> risk being left behind as compiler implementers make their own
>> "standards".  Such fragmentation would not be good for anyone.
>> (In this case, most but not all compilers have gone for the same
>> format for binary literals.)
> 
> And that could be a good argument to make, except that it should
> be based on some sort of objective evidence, not just what person
> X or person Y thinks is true.
> 
>> I would be quite happy with the idea of a subcommittee producing
>> an extension to the C standards to cover features such as this
>> that would suit embedded programming - as long as it is an
>> "official" standard with a similar weight to the main C standards.
>> A standard such as this could include many additions, refinements,
>> restrictions or enhancements to the main C standards that for some
>> reason are undesirable in the main standard.
> 
> This path may be a more fruitful path to go down for what you
> want to do, both because the energy barrier is probably lower and
> because if there were such a subgroup consensus then that could
> be taken to compiler vendors for them to retrofit into existing
> C99 implementations.  Whatever it is that ISO might end up doing
> about this question, one thing we can be sure of is that they
> will not make a retroactive change to previous versions of the
> standard.
> 

(The committee have arguably already made retroactive changes to
existing standards, by making parts of C99 optional in C11.  But my
interest here is for future standards, not old ones.)

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

Thread

Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-29 08:55 -0700
  Re: Spurious diagnostic messages supercat@casperkitty.com - 2015-09-29 10:22 -0700
    Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 23:42 -0700
      Re: Spurious diagnostic messages supercat@casperkitty.com - 2015-10-05 09:41 -0700
        Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-09 13:22 -0700
  Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-09-29 22:28 +0200
    Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-05 00:14 -0700
      Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-10-05 10:30 +0200
        Re: Spurious diagnostic messages supercat@casperkitty.com - 2015-10-05 10:06 -0700
          Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-10-06 09:23 +0200
            Re: Spurious diagnostic messages supercat@casperkitty.com - 2015-10-06 11:18 -0700
              Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-10-06 14:29 -0700
                Re: Spurious diagnostic messages supercat@casperkitty.com - 2015-10-06 15:33 -0700
                Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-10-07 12:35 +0200
              Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-10-07 10:57 +0200
                Re: Spurious diagnostic messages supercat@casperkitty.com - 2015-10-07 07:09 -0700
                Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-10-08 09:28 +0200
                Re: Spurious diagnostic messages supercat@casperkitty.com - 2015-10-08 01:45 -0700
                Re: Spurious diagnostic messages glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-08 09:42 +0000
                Re: Spurious diagnostic messages supercat@casperkitty.com - 2015-10-08 09:42 -0700
                Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-10-07 09:40 -0700
                Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-10-08 09:44 +0200
                Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-10-08 08:25 -0700
                Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-10-08 20:36 +0200
                Re: Spurious diagnostic messages Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-08 13:28 -0700
                Re: Spurious diagnostic messages Bartc <bc@freeuk.com> - 2015-10-08 22:21 +0100
                Re: Spurious diagnostic messages supercat@casperkitty.com - 2015-10-08 14:33 -0700
                Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-10-09 10:24 +0200
                Re: Spurious diagnostic messages supercat@casperkitty.com - 2015-10-09 08:35 -0700
                Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-10-11 15:18 +0200
                Re: Spurious diagnostic messages supercat@casperkitty.com - 2015-10-11 14:53 -0700
                Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-10-12 09:17 +0200
                Re: Spurious diagnostic messages supercat@casperkitty.com - 2015-10-12 00:37 -0700
                Re: Spurious diagnostic messages Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-10 00:31 -0700
                Re: Spurious diagnostic messages Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-10 10:50 +0100
                Re: Spurious diagnostic messages Bartc <bc@freeuk.com> - 2015-10-10 11:01 +0100
                Re: Spurious diagnostic messages Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-10 03:43 -0700
                Re: Spurious diagnostic messages supercat@casperkitty.com - 2015-10-10 13:26 -0700
                Re: Spurious diagnostic messages supercat@casperkitty.com - 2015-10-10 13:34 -0700
                Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-10-11 15:25 +0200
        Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-14 07:43 -0700
          Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-10-14 17:00 +0200

csiph-web