Re: More C type errors by default for GCC 14

[Gabriel Ravier <gabravier@gmail.com>]

On 5/12/23 15:19, Po Lu via Gcc wrote:
> Jonathan Wakely <jwakely.gcc@gmail.com> writes:
>
>> It's not about popularity. If that's your takeaway then you're not
>> paying attention, whatever you claim about reading everything in the
>> thread.  It's about helping people write correct code, first time,
>> without some of the avoidable traps that C presents.
>>
>> The C ecosystem has a shockingly bad reputation when it comes to
>> security and "just don't write bugs" is naive and ineffective. Maybe
>> you're good enough for that to work, but then you should also be able
>> to cope with a change in defaults.
> Right, and how many percent of those came from implicit function
> declarations?  Implicit int?  Extern declarations in function scope
> being applied at file scope?  Arithmetic between floats being done as
> doubles?  Narrow-type promotion to unsigned int?
>
>> It's time for some defaults to change so that modern C is preferred,
>> and "implicit everything, hope the programmer got it right" requires
>> explicit action, *but it's still possible to do* for the 1970s
>> nostalgia fans.
> It is impossible for implicit int to lead to bugs.
...You're joking, right ? You can't possibly be seriously arguing this, 
you have to be kidding... right ?
>
>> If you want to believe that's the start of a slippery slope, that's
>> your choice. The nostalgia club can always fork gcc if necessary,
>> that's one of the great things about free software.
> I am not part of a nostalgia club, so you might as well stop using this
> label.  In courtrooms, the plantiffs may be precluded from using
> terminology that can mislead the jury.  This is more or less equivalent.
>
>> GCC has always taken backwards compatibility seriously. That doesn't
>> mean it is the prime directive and can never be violated, but it's
>> absolutely always considered. In this case, changing the default seems
>> appropriate to many people, including those who actually maintain gcc
>> and deal with the consequences of the current defaults.
> What consequences?  Really?
>
>> Do you have anything new to add other than repeating the same
>> arguments? We've heard them now, thanks.
> Yes, just these quotes from a former GCC maintainer:
>
>    In C, we cannot divide all user code into "right" and "wrong" in this
>    kind of simple way, and certainly not based on the ISO standard.  That
>    standard is just the decisions of a certain committee (which I was a
>    member of) about what cases conforming compilers should commit to
>    support.  We must not let ourselves start thinking that C code is
>    "wrong", just because it is not conforming ISO C code.
>
>    C programs use many cases that are not conforming, but do work.  This
>    will be true for as long as C is used, because changing it would
>    require major changes in the C language.
>
>    From time to time, there is a real *need* to make some of these cases
>    stop working, for the sake of some benefit that users want.  When this
>    happens, we should do it; the user community will accept it, because
>    they will see that it is being done for their sake.  Some will
>    grumble, but the users who appreciate the benefits will convince them.
>
>    But when there is no *need* to break these cases, when we can keep
>    them working fairly easily, we should keep them working.  If we break
>    them unnecessarily, we invite the legitimate anger of the users.
>
> and:
>
>    You are arguing for a position that rejects the very idea of making an
>    effort to keep old code working.  Your arguments support a general
>    conclusion that "If code is not unambiguously valid, it is better to
>    break the code than to keep it working."
>
>    This is not just a harsh policy, it is an explicit policy of being
>    harsh.  That is, it says, "Be harsh!  Choose the alternative that is
>    harsh!"  This is the opposite of the way we should treat our users.
>
>    I understand that your views are not based on sadism or cruelty; you
>    think that treating users harshly is better for them.  But your
>    motivation, like my motivation, is not the issue anyway.  To adopt a
>    policy of harshness towards people--no matter what justification is
>    offered for it--is treating them badly.  That is the wrong way to
>    treat the users.  We must not make GCC decisions based on a policy of
>    harshness.
>
>    I would like future GCC decisions to be based on the policy that
>    keeping old code working is a good thing to do, when it is practical
>    of course.
>
>    So if any argument leads to the conclusion that one should be harsh to
>    the users, please recognize where the argument is taking you, and
>    reject it on the grounds that it is a disguised policy of harshness.
>
>    In particular, if it is argued that a policy of kindness has a
>    disadvantage, and it turns out that the disadvantage is a consequence
>    of the fact that the users have been treated kindly, it is really a
>    disguised policy of harshness.
>
> It is sad that this mature attitude no longer seems to be prevalent
> among the current maintainership.