Re: bug and fix for cpp

[Mike Karr <mkarr at mathworks dot com>]

Dave,

>  I can see that the patch is safe (i.e. it won't break anything),

That's good to know; it was what I wasn't sure of.

>  but I need to understand why it is necessary. Can you point out
>  where in the existing code problems arise with your test cases? I
>  assume that the free_ptr on the input stack is freed at some point
>  where it is still needed.

Suppose the top of instack has a buffer whose contents is something
like "f(x1, x2".  The first element of args points into this buffer
starting at x1.  Then argument processing for the second argument
doesn't find the terminating comma or left parenthesis, and pops the
stack to continue the scan.  Popping the stack previously freed its
buffer, thereby leaving the first element of args pointing into freed
data, as you suspected.

It was always an error, although it was somewhat tricky to find small
examples that manifested it, I think because the over-allocation of
some buffers which often leaves the freed and re-malloc'ed contents
intact.  I believe if you use purify or mallocdebug or equivalent
packages, the problem will show up whenever you have a sequence of
macros like:

#define m3(a, b, c) a##b##c
#define m2(a, b) m3(a, b
#define m1(AB, c) m2 AB, c)
m1((x, y), z)

The last line should expand to xyz.

hth,
mike