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

Groups > comp.lang.c > #154338

Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide

Show all headers | View raw

Richard Damon <Richard@Damon-Family.org> writes:

> On 8/12/20 6:05 PM, Elijah Stone wrote:
>
>> On Wed, 12 Aug 2020, Keith Thompson wrote:
>>
>>> There is a valid point here, that C's requirements for diagnostic are
>>> rather weak, but most or all compilers do provide options to enforce the
>>> rules strictly, and I think most production code is written to follow
>>> the rules.
>>>
>>> C isn't nearly as lax as he implies it is.
>>
>> He spends a long time talking about this;  see the section titled 'We
>> Consider Warning Changes, Breaking'.  They are unwilling to add new
>> warnings /because/ people compile with -Werror and the new warnings will
>> cause people's code to break.
>
> I suspect part of the problem is that the category 'Warning' has a very
> big span of meaning.
>
> Some things are warning because they maybe should have been an error,
> but was downgraded to just a warning as some extension uses this.
>
> Some things are warning because they are very questionable codeing
> practices.  Things like if (x = y) where they also provide a alternate
> valid sequence that will silence the warning like if ((x=y))
>
> Maybe slightly less onnerous warnings of possible questionable behavior
> like declaring unused variables.
>
> And at the very bottom, stylistic warnings, things like bad indenting.
>
>
> If the category warning was split up so that you could make -Werror only
> generate an error on the higher levels of these, but still allow the
> lower levels, you could add new warnings, maybe started at the lower
> levels and see how well it works.

I think an important point to remember is that these are tools
issues and not language issues.  Except for #error, the C
standard doesn't differentiate between "warnings" and "errors",
but regards the matter as a QOI choice (and IMO rightly so).
Also the question of severity is by its nature subjective.  One
developer's acceptable coding practice is another developer's
unforgivable sin (and similarly for programming teams, etc).
Different groups may reasonably make different choices about
which conditions should be treated as fatal and which conditions
are merely advisory (or some other category).  It would be nice
to see compilers evolve in the direction not only of which
diagnostic options are provided but also how individual tests and
sets of tests are treated (eg, "error" or "warning", or perhaps
even user-defined labels).  It's good to see gcc has gained some
flexibility in choosing how different tests are treated.

Back to comp.lang.c | Previous | Next | Find similar

Thread

Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-09-01 07:22 -0700

csiph-web