Re: [RFC] is_literal
| From: | Rowan Tommins | Date: | Tue, 15 Jun 2021 10:37:31 +0000 |
| Subject: | Re: [RFC] is_literal | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-114882@lists.php.net to get a copy of this message | ||
On 15/06/2021 08:19, Joe Watkins wrote:
https://3v4l.org/nJhc1/rfc#focus=rfc.literals It's not so much a bug as a side effect or quirk. Note that, the result is correct, in the sense that you do have a literal string - it is not marking an unsafe string as safe.It's possible to create more complex cases of this, e.g. https://3v4l.org/GFCQC/rfc#focus=rfc.literals $literal = 'p'; $ord = ord('o'); $chr = chr($ord+1); // the whole of chr(ord('o')+1) is optimized to a literal 'p' var_dump($chr, is_literal($chr)); // 'p', true There's a lot of potential for optimizations to leak there, but it's *probably* safe, as long as the optimizations all rely on compile-time information, and therefore can't be controlled by the user. Are there any run-time optimizations that could also be leaked, e.g. JIT? Regards, -- Rowan Tommins [IMSoP]