Re: dangling pointer bug and proposed patch

[Eric Blake]

Eric Blake <ebb9 <at> byu.net> writes:

> Answering myself,
yet again,

> I went one step further, and compared against Solaris 8's /usr/
> {ccs,xpg4}/bin/m4, with surprising results:
> 
> In a slight modification of your third example,
> 
> define(`f',1)f(pushdef(`f',2)f(define(`f',3)))f`'popdef(`f')f
> 
> GNU m4 gives "131", but Solaris gave "33f".  This seems like a Solaris bug, 
> since the pushdef failed to preserve the definition of f being "1".

On the other hand, maybe it is what POSIX intended.  The NEWS for CVS head 
claims that "* POSIXLY_CORRECT and `m4 --traditional' now makes the `define' 
builtin replace all `pushdef'ed values of a macro, as POSIX requires."  In 
light of that, Solaris' behavior makes perfect sense - the inner define wipes 
out the stack of definitions, leaving only a single definition for f.  Then the 
outer f uses the (one and only) current definition for f, and the popdef 
removes the last definition.

But trying that on CVS head of GNU m4 shows that we have regressed from 1.4.x:

$ POSIXLY_CORRECT=1 ~/m4-head/tests/m4 -dqeat
define(`f',1)f(pushdef(`f',2)define(`f',3))f
/home/eblake/m4-head/tests/m4: line 7:  6100 Segmentation fault      (core 
dumped) "/home/eblake/m4-head/src/m4" --module-directory="/home/eblake/m4-
head/modules" ${1+"$@"} 2>/tmp/m4-$$
m4trace: -1- define(`f', `1')
m4trace: -2- pushdef(`f', `2')
m4trace: -2- define(`f', `3')

Ouch.  At this point, I'm not sure how much effort should be put into making m4 
1.4.x POSIX compliant, vs. just making it coredump free, but now we also have 
to fix CVS head.  And if we fix head differently than 1.4.x, we are likely to 
get complaints that behavior has broken when people upgrade to the eventual 2.0.

-- 
Eric Blake