Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128926
Precedence: list
MIME-Version: 1.0
Date: Thu, 23 Oct 2025 10:21:31 +0200
To: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Deprecate Undefined Constant Usage in php.ini Files
 (GH-20060)
In-Reply-To: <775eb41b-7d5b-4da6-8f31-834de92b4ac8@rwec.co.uk>
References: <2abf50cd-5738-48e0-af15-a8c010141deb@bastelstu.be>
 <1760945334276.4002170669.2593555531@yahoo.de>
 <775eb41b-7d5b-4da6-8f31-834de92b4ac8@rwec.co.uk>
Message-ID: <be300f1b99576cf62bab6f424a4dc2df@bastelstu.be>
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

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