-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 According to john on 1/18/2006 7:37 PM: > Hello, > > There is a dangling pointer bug in GNU m4, exposed by this example: > > $ m4 -dqeat > define(`f',`one')f(undefine(`f')`two') > m4trace: -1- define(`f', `one') > m4trace: -2- undefine(`f') > m4trace: -1- øò·øò·(`two') -> `øò·øò·H' > øò·øò·H ... > I've written up the gory details (mostly to help me make sure I > understand them), including justification of the proposed behaviour, > in the attached PDF.
I see your copyright assignment went through in March; sorry it has taken so long, but I am finally looking at this patch. Thanks for an excellent bug report! First, I claim that some of the behavior you call unspecified in section 2 is actually specified. For example, you mention define(`f',`one')f(define(`f',`two')) According to POSIX, "Macros may have arguments, in which case the arguments shall be substituted into the defining text before it is rescanned." So the argument "define(`f',`two')" is expanded to void, then plugged into the defining text of f (which is now `two'), resulting in "two" as you note. You later ask the question in section 5 whether stripping whitespace is acceptable. My claim is yes, such as on this example: define(`f',`one')f( undefine(`f')two) The expansion of " undefine(`f')two" is "two", so you are substituting "two" into the definition of f; as there is none, the result should be "f(two)". However, I'm still not sold on your analysis in section 3 that define(`f',`one $1')f(pushdef(`f',`two $1')f(popdef(`f')three)) should result in "one one three". I think it might be more reasonable if it resulted in "one f(three)", where the innermost expansion of f uses the innermost definition of f at that time (it is undefined, resulting in "f(three)") rather than falling back to an outer definition (resulting in "one three"). The difference of my interpretation vs. yours would be that if SYMBOL_DELETED(sym) is true, I would always use $0($@) at that point, rather than falling back to any earlier definition that is still defined. Does any other m4 guru want to weigh in on this analysis? - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEYelq84KuGfSFAYARAvnuAJ9Vj6k/AfYYK7VtkvCmQaEjoLiqGACguytV pWImjV+yS39cmNm0tE8KrKo= =7VNU -----END PGP SIGNATURE----- _______________________________________________ Bug-m4 mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-m4
