On 5/12/23 15:19, Po Lu via Gcc wrote:
Jonathan Wakely <jwakely....@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.
