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
Thread (8 messages)