Re: make-3.80: `eval' bug

[Paul D. Smith]

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