[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: make-3.80: `eval' bug
From: |
Paul D. Smith |
Subject: |
Re: make-3.80: `eval' bug |
Date: |
Thu, 24 Oct 2002 19:04:27 -0400 |
%% address@hidden (Toomas Rosin) writes:
tr> Well, make's code is not easy to debug (deep recursion), and I
tr> have not done this before. I certainly do not see all the issues
tr> even now, after spending a long and busy day gdb'ing it. I simply
tr> tried to find the simplest working solution.
Sorry; I certainly didn't mean to dis your work; you got much farther
than most :). If you like you might save some debugging time next time
by dropping a line to address@hidden to see if anyone else has hit it.
Of course, the debugging can be fun and you definitely learn a lot more
that way :).
pds> However, the basic idea behind your proposed fix might be cleaner
pds> than my solution; I'll have to think about it.
tr> Well, my version is perhaps better in that it makes the `func_*'
tr> functions uniform.
That doesn't matter much to me: eval is a special function and if,
internally, it is implemented in a way different from the other
functions that's OK w/ me.
I find it cleaner (perhaps) because it better preserves the concept of
the variable_buffer and how it is used everywhere else in the code (not
just the functions). The fact that it has never been necessary to write
a push/pop function before shows that the paradigm has worked.
Now, as I said, I don't really like this paradigm: the knowledge of when
you need to use an allocated output buffer versus a normal output buffer
requires some pretty deep understanding of many areas of the code, which
I don't think should be necessary. I would like to replace
variable_buffer with something different, a very lightweight
"scratchpad" implementation I've been working on as a _very_
low-priority item.
But up until that change I would prefer to follow the existing paradigm
where possible rather than inventing a new one--that seems to me to be
even more gross :).
pds> Pushing/popping the buffer is very safe, but kind of gross.
tr> I would say "simple and robust" instead of "gross" :-) Had I got
tr> the idea, I would not have hesitated to use it. In the process of
tr> creating my own fix, I felt unsafe all the time.
I mean "gross" in this specific context, given that so far the code has
not needed it. Or, put another way, to me it's almost always more gross
to invent a new, additional API than to simply continue to use what is
already used everywhere else :).
--
-------------------------------------------------------------------------------
Paul D. Smith <address@hidden> Find some GNU make tips at:
http://www.gnu.org http://make.paulandlesley.org
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist