Bug #79044 [Com]: Curly Braces Throw T_LNUMBER Error
Edit report at https://bugs.php.net/bug.php?id=79044&edit=1
ID: 79044
Comment by: a at b dot c dot de
Reported by: thebluewalrus at gmail dot com
Summary: Curly Braces Throw T_LNUMBER Error
Status: Not a bug
Type: Bug
Package: *General Issues
Operating System: Mac OSX 10.12.4
PHP Version: 7.4.1
Block user comment: N
Private report: N
New Comment:
Wouldn't that mean munging the input to PCRE, because it's the library specifying the use
of "$1" to refer to pattern replacements? (And you can blame Perl for that.) Don't
forget to also handle its use of {} to disambiguate between ${1}0 and $10.
Just one MORE reason to prefer single quotes when writing string literals in those function calls.
Previous Comments:
------------------------------------------------------------------------
[2020-01-01 16:53:12] thebluewalrus at gmail dot com
So the 'complex syntax' is not as advanced as the regular variable processor but the
behavior of the 'complex syntax' will not be corrected because that is how it has been for
ages?
It would seem to me that
\{\$[a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]*\}
would be better than
\{\$[^}]+?\}
which is what I presume the regular variable processor uses. If it's not a variable it
shouldn't process it. I can't see how this would break past functionality, Previously the
complex failed in instance where it shouldn't have.
------------------------------------------------------------------------
[2019-12-30 00:04:54] bugreports at gmail dot com
> Unless, of course, you have a compelling reason why
> PHP should suddenly break functionality that has
> been allowed since basically forever?
well, nobody right in his mind would write "$1test" instead "\$1test" and call
that simply *udenfeined* hehavior given that yiu are supposed to escape $ within double quotes and
undefined behavior by it's definition can change at whatever point in time
------------------------------------------------------------------------
[2019-12-29 23:42:48] requinix@php.net
> irrelevant
By all means, please invent a time machine and go back a couple decades to tell the people
developing PHP that they should have done this differently. That way people in the other timeline
won't have to deal with such utterly ridiculous behavior. I know that for me, personally, if I
were to fork PHP, prohibiting writing "$1" is at the top of my list of things to change.
Meanwhile for those of us in this timeline, that's how it is. Unless, of course, you have a
compelling reason why PHP should suddenly break functionality that has been allowed since basically
forever?
If you actually do despite my sarcasm, go ahead and start working on an RFC for it. I'm sure
everyone will love it.
------------------------------------------------------------------------
[2019-12-29 23:10:49] bugreports at gmail dot com
irrelevant, the second one should throw the same error than the first and that can even throw at
compile time
php > echo $1test;
Parse error: syntax error, unexpected '1' (T_LNUMBER), expecting variable (T_VARIABLE) or
'{' or '$' in php shell code on line 1
php > echo "$1test";
$1test
------------------------------------------------------------------------
[2019-12-29 22:44:18] requinix@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to
report
a bug at http://bugs.php.net/how-to-report.php
https://www.php.net/manual/en/language.types.string.php#language.types.string.parsing
When PHP reads the simple syntax it sees the '$' and takes
> as many tokens as possible to form a valid variable name
No tokens means no variable and PHP ignores it.
Complex syntax works differently as it
> allows for the use of complex expressions
With complex syntax PHP sees '{$' and everything up to the closing '}' is used.
In other words, PHP looks for a valid expression - the kind you use in your regular code, but with
the obvious limitation that it has to start with a dollar sign.
"$1" is not a valid expression, and PHP raises the same syntax error that it would as if
you wrote that outside of a string.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=79044
--
Edit this bug report at https://bugs.php.net/bug.php?id=79044&edit=1
Thread (9 messages)