Re: Deprecate Undefined Constant Usage in php.ini Files (GH-20060)
| From: | Tim Düsterhus | Date: | Thu, 23 Oct 2025 08:21:31 +0000 |
| Subject: | Re: Deprecate Undefined Constant Usage in php.ini Files (GH-20060) | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-128926@lists.php.net to get a copy of this message | ||
Hi
Am 2025-10-20 20:17, schrieb Rowan Tommins [IMSoP]:
I don't think this kind of pattern matching is the right way to go. It's perfectly normal in INI files to have all sorts of strings which aren't quoted; looking through the samples provided in the source, I spotted this: user_agent=PHP No regex is going to recognise that that should be interpreted as "PHP", not constant("PHP").I agree with that. Supporting bare strings is a key feature and randomly warning for *some* of them is going to be even more confusing than just some of them randomly getting replaced by a different value just because they happen to match a constant. In fact this made me realize that
parse_ini_*() is unsafe, because it doesn't just support *internal* constants, but also constants defined in userland. I have thus just proposed a new warning to be added to the documentation: https://github.com/php/doc-en/pull/4946.
Given that the primary purpose of the constant support seems to be the E_* constants for error_reporting, it might be best to instead only support a small allow-list of safe constants in INI files.
Best regards
Tim Düsterhus