Re: type based aliasing again

[craig at jcb-sc dot com]

This is in regarding to jsteven, who wrote:
>> >[Snippage abounds, mostly personal attacks, bald assertions and
>> > repetitions, but some other things may have been inadvertently
>> > snipped.]
>> 
>> Unfortunately, this individual chose to post quotes from my *private*
>> email to him on this list, despite my *explicit* explanation, at
>> the top, that I was taking this off-list.
>
>I was the first to send private email.  You responded by posting
>quotes from that email back to this list, with the statement:
>
>"back to the list, where this belongs"
>
>If my action pisses you off, perhaps you should not have done the
>same to me, first.  After all, it gave me the impression that this
>was not only Ok with you, but preferable.

I'm very sorry to still be posting to this list at this time, but
felt it appropriate to provide the rest of the snippets I'd edited
from the "private" email he sent to me earlier, to ensure that my
response didn't accidentally constitute taking him out of context,
edit away important qualifiers to set up strawmen, and so on.

Yes, I had forgotten he'd emailed me "in private" earlier in this
thread, but I'll note several things about that:

  1.  He didn't say anything at the top of the email indicating he
      *wanted* it kept private.  As a long-time GCC/g77 maintainer, I
      *often* get private emails that were clearly intended for some
      list.  Though one or two others here have resorted to indicating
      they'd forward such emails to pertinent lists in their .sigs,
      I hadn't yet decided to start doing that.  I don't recall ever
      being taken to task for forwarding private emails, or my
      responses quoting them, to the suitable list of which I was
      generally recognized as a contributing member (else I wouldn't
      have gotten that email from that person in the first place).

  2.  I don't believe I ridiculed any "views" of his constructed (in
      my email in response to his private email) by eliminating important
      text in that email.  If anyone disagrees, they are welcome to
      send me private email pointing out where and how I did that, at
      which point I'll look into it and decide whether to issue a
      specific apology.  (Make it public email to this list if you're
      convinced I did it intentionally and thus are uninterested in
      any response I might give explaining myself.)

  3.  When I posted that material back to the list, RMS hadn't yet
      written this to me (or, I hadn't seen it):

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

      Among other things, this *later* convinced me to take further
      discussions -- especially over my earlier, long email to
      jstevens, which got into a lot of extra-GCC issues -- off-list.

      And there is evidence in jstevens' own email that he, too, had
      seen and been aware of this, where he apparently responded to
      my reference to RMS' statement(s):

>> But, we're now told, it *is* to be thought of as the responsibility
>> of GCC.  And I'm told not to object to that anymore.
>
>Actually, you were *requested*, quite politely, not to exagerate
>so much.

  4.  In the private email I *did* send to jstevens, I *explicitly*
      specified the following in the very first line:

>[I'm no longer discussing this on the list.]

      I don't see why that's so hard to understand.  A simple request
      for permission would have sufficed.

      Further, I don't understand how he could have been *sincere*
      in his desire to be helpful (in the sense GCC maintainers, like
      myself, are when we take private emails *to* the list) by not
      even commenting on, or *quoting*, that statement!  (I.e. that's
      the first time anyone *here* has seen that line.)

  5.  jstevens is not a maintainer of GCC (not listed in MAINTAINERS,
      for example).  Email going from a maintainer to a non-maintainer
      is not nearly as fairly interpreted as being "appropriate for
      the list" as email going in the other direction, as happened when
      jstevens sent his email to me.  After all, I couldn't have been
      reasonably interpreted to have been trying to change the direction
      of GCC by sending jstevens email, since he is *not* a maintainer --
      even aside from the fact that I'd explicitly said I wanted the
      email to not go back to the list!

      In short, I don't see why it was unfair for me to interpret his
      email to me as advocacy to me *as a GCC maintainer*.  If I'd
      kept my response private, we could have argued for awhile perhaps,
      but that would have denied others an opportunity to correct *me*,
      something quite likely given that I've definitely been in the
      minority in terms of my views (just as I was back in December
      vis-a-vis the 80-bit-spills issue -- so it's not a new role for me).

      But I also don't see why it was fair for him to assume any email
      I sent to him *explaining my views* as a GCC maintainer should
      automatically be assumed to be publicizable.

      That jstevens sees the two as equivalent, even if he was entirely
      ignorant of my longstanding role as one of GCC's maintainers, I
      find implausible, given the evidence in the emails itself, and his
      own culpability in editing them where he had opportunity to do so.

  6.  When I read jstevens' *public* response, I skimmed it, and quickly
      noticed that not only did he override my *explicit* decision to
      take this off-list, he'd apparently intentionally omitted some
      material I'd written that would have otherwise rendered his attacks
      on my so-called "views" (few of which, based on his rendering of
      them, I actually hold) unsupportable -- one in particular I can
      identify, along with another one so he could act as if another issue
      had never occurred to me.

      IMO, when someone takes a private discussion into public, he has
      a duty to fairly represent the private discussion, even if he
      disagrees with it.  As I said in point 2 above, I believe I made
      a sincere attempt to do so when I quoted his private email in
      my response to the list.

      I don't consider jsteven's corresponding effort to have been
      successful, and, given other aspects of this situation, question
      its sincerity, especially since his public email began with:

>[Snippage abounds, mostly personal attacks, bald assertions and
> repetitions, but some other things may have been inadvertently
> snipped.]

      In other words, he chose to *publish* my so-called "personal attacks,
      bald assertions and repetitions", despite my explicit statement
      that I was taking this discussion off-list.  If he had been so
      concerned about "personal attacks" of mine, why did he refer to
      them without *posting* them, except possibly to just trash my
      *public* reputation?

Finally, that a GCC Steering Committee member publically referred
to my email -- which he had *not* seen, nor has since asked to see --
as containing "fallacious reasoning" in his *thanking* of jstevens
for the behavior (which I describe above) strikes me as indicating
a terminal state of disrespect -- quite literally the last, though
huge, straw -- among some members of that Committee towards people who
have done their best (even when, in my case, it just wasn't good
enough) to make GCC (e.g. g77) a good product.  Given my other
commitments, that state of affairs strongly suggests to me that
this should be the *very* last post I make to this list.

Below are the snippets I've found that I removed from jsteven's
private email, to provide some additional context to my earlier
posting of a public response to his email sent in private.  Note
that any mistakes in this effort are mine, since I used Emacs
compare-windows to produce this and skip over my own commentary,
which is not an error-free approach.  I welcome anyone with the patience
and concern over my behavior to carefully examine my response to his
email and look for instances where my response (which I do not include
here, for brevity, and since it's in the archives) suggested I'd
intentionally removed his material just to make a point at his expense.

Also, if jstevens wishes to do the same with my earlier private email
(i.e. send the results of a similar effort to this list and welcome
comments), I hereby give him permission to do so.  If he doesn't do so
soon, I reserve my right to keep my own email to him private until such
time as I choose to make it public or share it with other individuals.

(Note: I'm still not discussing the original issues on this list anymore.
This email only serves to set the email-related record straight, not to
dredge up what has been deemed -- effectively by RMS, and then explicitly
by myself when it comes to my own opinions -- an off-topic discussion.)


Referring to jstevens' email <199909161750.LAA12073@basho.fc.hp.com>,
sent to me alone, which I only partially quoted in my public follow-up:

After:
>if you are unwilling to set the proper switch".

Came:
>IMO, that is a valid and reasonable response.  And I am an avid
>GNU/Linux fan, by the way.

After:
>gentle reminder of "traditional GCC mailing list" nomenclature.

Came:
>> >If we can warn the user by writing a reasonable amount of code then
>> >it seems to be the "nice" thing to do. Even if we can't catch all
>> >occurances (as is mentioned earlier in this thread), the ones we can catch
>> >may be quite a help to the user. 
>> 
>> I agree with that.
>
>Sounds good to me, too.  "Reasonable" being a decision left up to the
>GCC maintainers, of course.
>
>> If you, as a programmer, wish the behavior of your *program* to not
>> change, you can, as I said, simply designate a *particular* compiler
>> and version combination to use (for a particular platform, say).
>
>Right.  Kind of what I said: the users code is not incorrect, the
>action of mixing old code with a new compiler, however, may very
>well be incorrect.
>
>[ Neither the Philips head screw driver, nor the flat head screw
>  are incorrect.  It's the idiot who picked up *that* screw
>  driver to use on *that* screw that needs lessons.
>]

After:
>conforms to, right?

Came:
><IMHO>

After:
>conformance, first, of course.

Came:
></IMHO>

After:
>the compiler . . . ?

Came:
>> That's the problem with this whole notion that it is up to GCC to serve
>> as a sort of free-software installation tool.  It is the *programmer*,
>> not the installer, that needs to see the warnings.
>
>Right.  From this, I'm guessing that earlier you did mean that the user
>is not the user of the compiler, but instead the user of the program
>compiled by the compiler.
>
>If so, then I agree.  The programmer should take reasonable steps
>to generate warnings and errors (turn on warning switches, etc.),
>and then actually read 'em and do something about them.
>
>> Still, since C is not exactly a well-designed language, it is not
>> easy to write static-code-checkers (a la the lint-like facility of
>> GCC) to find all the problems typically committed by programmers.

After:
>C requires a huge amount of discipline to use correctly, and well.

Came:
>> >  It is unfortuante that it is immpossile to spew a warning on every
>> >instance of the alias problem, but I think it is necessary to provide a
>> >warning when we can do so with a minimum of effort.
>> 
>> I think everyone agrees to that.

After:
>Ditto.  As far as I can remember, the aliasing rules are *NEW*, so

Came:
>therefore, code that now breaks, was correct within the context of
>prior standards and practices, so therefore, GCC should warn
>the programmer that his once-correct code is invalid when compiled
>with this particular compiler.
>
>If the programmer chooses to ignore such warnings. . . well, tough!
>
>> What is not widely appreciated or understood is that this warning
>> *probably* will, itself, "change" across versions/releases of GCC,
>> and that programmers and users will be as upset about those changes
>> in *this* case as in the case of alias analysis becoming the default.

After:
>possible to warn me about it.

Came:
>> Am I wrong?
>
>I agree with you, with the one caveat re: "broken/buggy/incorrect"
>versus "incorrect to compile with this compiler when using default
>settings".
>
>> Well, after *tons* of exactly correct pointing out of
>> the issues, correcting *many* people on this list, as done by people
>> such as myself and Mark Mitchell, can anyone point to a *single*
>> example of anyone admitting they had been wrong and now understood
>> that they should not expect a compiler to never change the behavior
>> of their program, especially if it invokes undefined behavior according
>> to the pertinent language standard?
>
>The mental mistake here is: "the pertinent language standard".  There
>have been many "standards" (some defacto, some formal).
>
>WHICH STANDARD?

After:
>*that* code with *this* compiler, you'd be able to resolve this.

Came:
>The remaining complaints would be from people who believe that
>standards should never change.  Those people should be ignored.
>
>In response to your question, however: No, my mind hasn't changed,
>but that is because, in general, I agreed with you in the first
>place: New compilers that conform to new standards will require
>source code changes, if that source code was written to a different
>standard.

After:
>a "minefield"?

Came:
>> But anyone who thinks GCC developers can avoid this whole problem
>> (of huge amounts of argument about how GCC is "breaking programs")
>> by making it warn about this construct is, frankly, deluding themselves.
>
>The new GCC is, in fact, breaking programs when applied to programs
>that are written to a different standard than the one the new GCC
>conforms too.
>
>The fault, however, lies with the programmer who feeds that code
>to this GCC, not in GCC, or in the source code.
>
>Fair enough?

After:
>such errors and issuing warnings is not feasible).

Came:
>> Some people think GCC is a hand-holding catch-all for installing
>> free software from source, regardless of the correctness of that
>> source code (as long as it might have seemed to work on some
>> old version of some C compiler somewhere), or some approximation
>> thereof.
>
>I agree, this is a mis-conception.
>
>But I do believe in errors, warnings, etc.
>
>> That's why they think that GCC is now breaking programs by
>> defaulting to employing its alias analysis.
>
>As above, GCC is not to blame, unless GCC issues no warnings
>when it would be feasible and possible to issue such warnings.
>
>If it isn't feasible/possible, then: to bad (the standard probably
>should be modified, though).  In that case, however, a large, well
>written body of documentation should be produced and then distributed
>with the compiler that describes the situtation.
>
>You say: "I don't read the docs!"?
>
>To bad for you, then.
>
>John S.
>
>[ "I don't believe any of my wants or desires are unreasonable!"
>
>  "A true sign of a distrubed mind, that."
>
>  Overheard at the bar, at a Java conference.
>]

        tq vm, (burley)