From mboxrd@z Thu Jan  1 00:00:00 1970
From: craig@jcb-sc.com
To: dje@watson.ibm.com
Cc: craig@jcb-sc.com
Subject: Re: type based aliasing again
Date: Thu, 30 Sep 1999 18:02:00 -0000
Message-ID: <19990915165930.15281.qmail@deer>
References: <9909151630.AA36168@marc.watson.ibm.com>
X-SW-Source: 1999-09n/msg00635.html
Message-ID: <19990930180200.58fpjhqreaS_KX40WFHu6OjjEl29OeqCLejtOOYDk18@z>

>	This is arguing by generalization and generalizing to the
>extreme.  Different cases require different analysis and consideration.

So we can conclude that the expense (time and effort) needed to
address this *one* issue is:

  -  representative of what we're likely to expend over similar issues
     that *will* arise

  -  unlikely to serve as a boilerplate for analysis and consideration
     over those issues, sufficient that it significantly reduces the
     resources needed to analyse them

  -  not going to ameliorate problems users have compiling arbitrary
     C code off the 'net using GCC, since we'll likely come to different
     decisions than always defaulting to -fno-strict-analysis, even if
     we decide to do that now

  -  not going to serve too well in re-assessing whatever decision we
     make (*especially* one to change the default to -fno-...) in
     the future, since the future will hold all sorts of new
     information, thus leading to "different analysis and consideration"

Therefore, as I said near the very beginning of this most recent 'fest,
we shouldn't waste any time discussing issues like this.  Period.  We
should invoke the simplifying assumption that code which is violates
ISO C conformance rules is not worth bothering about.  That'll save
tons of resources (especially avoiding lots of wasted discussion) right
there.

Further, I realized, last night, that hoping that code needing this
special consideration will have finally been mothballed by the time
the default *has* to be changed (no question, no discussion worth
having) to accommodate Merced or McKinley amounts to entertaining
the same hopes, and therefore similar scaling of costs, as the
Y2K problem.  Most programmers who put Y2K bugs into code probably
just *knew* their code would be mothballed by 1995 or so anyway....

So people can either fix their code now, or fix it later.

Which is going to be more expensive for the industry as a whole?

        tq vm, (burley)