Martin Dorey <mdorey <at> bluearc.com> writes: > And it looks like there are several other instances of it too.
That's what I was afraid of. I looked at the other places where xrealloc could get called, but I couldn't find any that referenced the original buffer address after the xrealloc. I suspected that I might have missed some --- xrealloc is used really heavily. > >> What I am looking for is some help writing a makefile that > >> is simple enough to post in a bug report. > > I had a few goes but it looks like the variable_buffer is always already > big enough by the time it gets here. Can you tell us what rule it falls > over on for you or what trickery might be associated with that rule? Is > there, for example, re-reading of makefiles going on, or $(eval) magic? It is a static pattern rule, during the following function: main() -> snap_deps() -> expand_deps() This function calls patsubst_expand() on the rule target, and when patsubst_expand returns, the original buffer contents have moved. I tried reducing my makefile to just the two rules that trigger the bug (one that sets variable_buffer to the default size of 200, and one that busts beyond it), but somehow I can't get the variable_buffer to stay at 200 before it gets to the static pattern rule. Here's what I expected the reduced makefile to look like: a1: a%: b%; @echo trash a2222222222222222222222222222222222222222222222222222222222222222222222222222\ 2222222222222222222222: a22222222222222222222222222222222222222222%: c%22222222222222222222222222222222222222222222; @echo trash But somehow the variable_buffer is already big enough when it gets to the long rule. Dave _______________________________________________ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
