This is the mail archive of the
mailing list for the GCC project.
Re: [egcs 1.1] Fix gcc.c handling of %O vis-a-vis temp files
- To: Craig Burley <burley at gnu dot org>
- Subject: Re: [egcs 1.1] Fix gcc.c handling of %O vis-a-vis temp files
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Tue, 28 Jul 1998 23:01:12 -0600
- cc: egcs-patches at cygnus dot com, d dot love at dl dot ac dot uk
- Reply-To: law at cygnus dot com
In message <199807281337.JAA10632@melange.gnu.org>you write:
> And, my commentary for the patch, especially the ChangeLog entry,
> was suitably terse.
And that probably would have been OK if I had looked at things a little
closer or had a better understanding of what was going on with %g%O
and/or the specs stuff in general.
> Meanwhile, I have an IMO rather profound ability to think very long
> and hard about the most trivial technical matters, and a well-
> deserved reputation for writing long-winded stuff about them as well
> ("astute" readers claim it's all worthwhile, just verbose ;-).
Yup. It's an skill I need to cultivate for myself.
I tend to do a lot of hacking by the seat of my pants, slowing down and
diving deeper into seemingly trivial technical problems would be a
benefit for both me and the project. I can't even begin to count the
number of times slowing down and explaining a problem & solution in
detail has led me to better understanding of the problem and often to
a better solution to the problem.
> So when you say "hmm, I need more info", well, it's rather like
> waving a red flag at a bull, or an intern at Bill Clinton, or
> something -- you're going to get a response!
Yup. It just takes time to digest. I think I probably read your
message 4 or more times. Not because it was difficult to understand,
but because there were many good tidbits from both a technical and a
project management standpoint. Similarly for the message I'm replying
> I still don't think it was nearly as productive, overall, for you
> to take the time to email me your objections, thus basically forcing
> me to write responses, as it would have been for you to look up the
> docs for %O yourself and think about whether a patch to make %O work
> exactly the same as .o was a bug-fix vs. a security-related regression.
> In fact, I think that would have taken less time on your part in the
> end anyway, putting aside the time I've taken.
Yup. In hindsight I agree 100%. Which leads directly into....
> Not that such side issues aren't sometimes appropriate to raise, but
> some questions are worth asking yourself first, like:
> - Is the side issue something I'd entertain discussion on,
> independently of this patch, at this stage of the project?
> - Is there really any evidence the side issue is driving the
> the way the patch is constructed, or the way the design might
> be modified, rather than simply going along for the ride with
> a patch that is advertised as appropriate on its own terms?
Agreed. Part of my (unfounded) concern in this case was that the side
issue was actually the core problem. ie part of the issue I was trying
to resolve for myself was why weren't we seeing problems with %g%O
elsewhere. Is g77 doing something it should not be doing, or is it
just the case that it's doing something that isn't common elsewhere?
I'm pretty sure now that if I had looked a little deeper that my concern
about g77 would have easily been answered and we could have avoided this
discussion (then again, I think this discussion is *good*).
> Well, especially the latter, but the way you originally responded
> did suggest an assumption that *g77* was at fault, yet nothing in
> my patch said anything about accommodating such a fault.
Right. That was my concern and incorrect assumption.
> And, trust me, it would have -- I try to be quite up-front about
> the kludges that exist in g77, and still have several of them on
> my "fix" list, including at least two that, when done, will be
> accompanied by a patch to remove code from gcc that only g77 uses
> (well, one of them doesn't involve changes to FSF-gcc, but does to
Quite true. Sometimes I lose sight of how well you have kept us informed
of the warts.
> Yeah, but what's *really* scary is that now you, and maybe some other
> people, will think *I've* got a good understanding of this code, and
> will ask me questions later on about it.
:-0 You certainly know more about it than I do. Then again, now that
we've fixed the docs it shouldn't be quite as obscure. I was seriously
confused when I read %g's doc, then thought about "why are we using this?!?"
> And there's some validity
> to that view, because you've forced me to learn a whole lot more about
> this by asking so many questions. Everything I've learned supports
> my original patch's validity, of course, but...
And you've also broaded my knowledge in the process.
> ...the point is, I'm *already* having to cope with one badly-designed
> ancient language (Fortran), and hardly want to be seen as an expert
> on another one, even a "little" one like the specs file stuff. :) :) :)
> Note that *I* didn't have all the state originally, either. I tried
> to limit my exposure to this crufty area by learning just enough
> state to be quite comfortable making the change I did.
Yup. I do this often myself, particularly in areas where I do not expect
to spend a lot of time.
> >At this point I do not see a reason why your change should not go in.
> Great, thanks! But I suggest the ChangeLog entry be revised from
It's in. I'm going to go tweak the ChangeLog entry a little in a