Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128873
Content-Type: text/plain; charset=utf-8
Message-ID: <1760945334276.4002170669.2593555531@yahoo.de>
To: tim@bastelstu.be
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Deprecate Undefined Constant Usage in php.ini Files
 (GH-20060)
Date: Mon, 20 Oct 2025 09:16:51 +0000
In-Reply-To: <2abf50cd-5738-48e0-af15-a8c010141deb@bastelstu.be>
References: <2abf50cd-5738-48e0-af15-a8c010141deb@bastelstu.be>
User-Agent: Vivaldi Mail/7.6.3797.63
Content-Transfer-Encoding: quoted-printable
Precedence: list
MIME-Version: 1.0
From: hanskrentel@yahoo.de (Hans Krentel)




On Sunday 19 October 2025 22:09:52 (+02:00), Tim D=C3=BCsterhus wrote:

> Hi
>=20
> 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.
>=20
> That was not what I was asking for.
>=20
> 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=C3=BCsterhus
>=20


Hi Tim,

Thanks for the clarification, and my apologies=E2=80=94my 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 =3D
zend_get_constant(Z_STR_P(name)) !=3D 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