Re: type based aliasing again

[Richard Stallman <rms at gnu dot org>]

You have written a long message, as you often do.  It contains a
number of points that I disagree with, but I don't have time to
respond to them all.  So I have chosen the few that seem most
important.

    >I notice a pattern that people arguing against concern for the users
    >tend to exaggerate the situation in this particular way: they change
    >"some of this code may break, may need to be changed" into "all of
    >this code will break, will need to be changed."

    I didn't say that.  But, for the purposes of assessing these issues,
    that's how people maintaining their code should *think*.

It is a mistake to judge everything by worst-case costs instead of
likely costs.  That leads to decisions that increase the expected
costs.  In situations like this, it leads to a pattern of skewed
judgement, consistently being too harsh to users.

I wonder if some of the other people who have argued for harshness on
this issue are also making a conscious assumption of calculating costs
based on the worst case for kindness.  They are not assuming the worst
case for harshness!

    >In effect, your argument is that this proposal is a bad idea because
    >Craig Burley and others will spend time arguing against it.  I do not
    >think that the proposal can be held responsible for that ;-).

    If you view it that way, especially as a spokesman for the GNU project,
    which controls GCC, you are saying that the only real cost, in terms
    of added complexity, to being willing to consider changing the compiler
    to better accommodate broken code is that there will be some people
    who openly disagree with that policy and/or with the specifics of
    the proposal.

Yes.  Once people accept the principle of doing this kind of
accommodation, actually doing it will be easy.  The idea is that you
only spend a limited amount of time looking for a solution, and only
do something if you find an easy way.  This always has to be easy.

The only thing that is hard is when people argue, as you are doing,
against the very idea of accommodation.  So please don't do that.

    In effect, you are telling me that if I don't want GCC to become even
    more complicated and hard to maintain than necessary, or have bugs fixed
    in it less speedily due to long-drawn-out discussions like this, I should
    no longer participate in discussions like this, except perhaps to
    grunt things like "okay by me" or "no way".

Those thoughts are yours, not mine.  I am just asking you and others
to stop arguing for a policy of harshness toward the user--to stop
arguing against the very idea of trying to accommodate old undefined
code.

If you don't want GCC to be more complicated or for the work to go
slower, then you share my feelings on that issue.  That's why I looked
for a simple change that is clearly correct and will be easy to
implement.  In the future, I would like the GCC developers to look for
such changes, because this is what the GNU Project needs GCC to do.

    this discussion is that there have been quite a number of statements
    made that are either incorrect in fact or incomplete in portraying
    cost/benefit analyses vis-a-vis this issue.  Since *most* of those
    statements have been made to promote accommodation, 

I have seen a regular pattern of exaggeration in the messages arguing
for harshness.  The worst always can happen, but it is very unlikely
to happen always.

    Programmers should view bugs in their code like termites.

I think you are partly right, but not entirely, because you are
demanding a strictness that is more trouble that it's worth for many
projects, and is also more work than most free software developers can
manage to do.  Fortunately, a somewhat more relaxed approach works
pretty well.

Be that as it may, that question is a side issue.  You are talking
about programmers running GCC on code that they are developing.  Those
are just some of the users of GCC.  Only some of the people running
GCC are running it on code they understand, or could attempt to debug.

We must not make GCC decisions with only those people in mind.

    But, I believe the analysis for GCC *itself* is *much* simpler:
    conform to the pertinent ANSI/ISO standards, etc.

GCC does conform to these standards, when used with the proper set of
options.  However, technical standards are not a moral authority.  The
GNU Project policy is that we pay close attention to official
standards, but we don't slavishly obey them.

In this case, the issue is not even whether GCC complies with the C
standard.  It concerns the behavior of GCC in a case which the C
standard does not specify.