ZF-6996: Parameter descriptions are incorrectly parsed by Zend_Server_Reflection_Function_Abstract _reflect() regular expression
Description
Zend_Server_Reflection_Function_Abstract, line 296:
This regular expression is to extract the parameter name and description from a parameter definition comment:
The part that scans for a variable name, ``` I.e. "dollar sign followed by one or more characters that are not - not whitespace" must read "dollar sign followed by one or more characters that are not whitespace"
Comments
Posted by Stephen Leavitt (subzero2000) on 2009-07-21T20:53:33.000+0000
Actually, the regex means "dollar sign followed by the beginning of a line followed by one or more characters that are not whitespace".
A circumflex outside of a character class (square brackets) means the beginning of a line, whereas a circumflex as the first character in a character class means that the character does not match any of the characters in the character class.
The part that scans for a variable name,
should instead read
i.e. just remove the extraneous circumflex
Posted by Stephen Leavitt (subzero2000) on 2009-07-21T20:57:26.000+0000
Actually, I just discovered that a circumflex used outside of a character class is an assertion which is true only if the current matching point is at the start of the subject string, which does not necessarily imply the beginning of a line.
[http://php.net/manual/en/…]
Posted by Stephen Leavitt (subzero2000) on 2009-07-21T20:59:25.000+0000
Uploading patch previously uploaded to ZF-7344, which is a duplicate of this issue.
Posted by Penny Leach (mjollnir) on 2010-01-24T21:19:56.000+0000
I was affected by this too, and came to exactly the same patch before finding this bug. It would be great if this could be fixed! :)
Posted by Matthew Weier O'Phinney (matthew) on 2010-01-25T12:12:23.000+0000
Fixed on trunk and 1.10 release branch.
Posted by Marc Bennewitz (private) (mabe) on 2010-01-25T13:45:23.000+0000
This patch crashes Zend_Json tests:
Posted by Matthew Weier O'Phinney (matthew) on 2010-01-25T14:34:06.000+0000
Fixed in trunk and 1.10 release branch. Fixing this issue exposed another issue, basically, and this is now resolved.