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