Re: Deprecate Undefined Constant Usage in php.ini Files (GH-20060)

On Sunday 19 October 2025 22:09:52 (+02:00), Tim Düsterhus wrote: > Hi > > On 10/19/25 21:47, Hans Krentel wrote: > > As it does today, no change. If you use a word that would expand to a constant name as it > > does today, you need to quote it. > > That was not what I was asking for. > > You are proposing to warn for undefined constants. How do you plan to warn only for undefined > constants, but not for unquoted strings? > > Best regards > Tim Düsterhus > Hi Tim, Thanks for the clarification, and my apologies—my previous, shorter answer missed the mark. Let me outline my understanding in greater detail. As noted in the implementation notes, I looked into zend_ini_get_constant() and saw that the zend-ini parser doesn't handle all unquoted strings, but only those matching IS_CONSTANT_AST, which stems from: CONSTANT [a-zA-Z_][a-zA-Z0-9_]* My proposal is to apply the same test (Z_OPT_CONSTANT(tmp)) *before* probing for the constant's existence (currently done via `c = zend_get_constant(Z_STR_P(name)) != 0`). This would address the current ordering flaw in the parser as an incidental improvement. More importantly, regarding your question, I've now looked more closely at the CONSTANT regex and realize I was mistaken: I had assumed it matched uppercase-only names, but it actually includes both upper- and lowercase letters. So, there would indeed be a change compared to my earlier answer: I now propose using only uppercase names for constant resolution (and thus for the warning you asked about). This would mean: - Allowing unquoted strings with lowercase characters to pass through unchanged. - Restricting constant name resolution to a pattern like: CONSTANT_NAME [A-Z_][A-Z0-9_]* ...possibly with a minimum length greater than one, as shown. In my view, this improves clarity in configuration contexts--at this level, case-folding to lowercase shouldn't be necessary. That said, your perspective may differ, and perhaps this was exactly the point you were raising. This revised understanding also suggests a more granular approach to differentiating cases, enabling richer behavior. But first, I'd appreciate your feedback on this more detailed reply. Best regards, Hans