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

Hello list,
I'd like to propose a change in PHP behaviour and would like to request
your comments.

Find my proposals' draft below.

Thank you in advance for your attention and thoughts, as usual I can
benefit from your help. If you have voting power and would consider
to vote on the topic, your rejection or acceptance rationale
appreciated. I would like to draft an implementation and could
incorporate the feedback then beforehand already.

Best,

-- hakre

Deprecate Undefined Constant Usage in php.ini Files

The php.ini file parser (as used by parse_ini_file()) supports
constant resolution, including core predefined constants. However, the
current behavior with undefined constants is inconsistent with PHP 8's
strict handling of undefined constants in regular PHP code.

Problem Statement

Current Inconsistent Behavior

In PHP 8 scripts, undefined constants trigger immediate fatal errors:

 <?php
 $var = X_ERROR; // Fatal error: Undefined constant "X_ERROR"

However, in php.ini files, undefined constants are silently handled
using PHP 4-era semantics:

 [PHP]
 error_reporting = X_ERROR|E_WARNING|E_PARSE|E_NOTICE

This silently:

1. Converts X_ERROR to string "X_ERROR"
2. Converts that string to integer 0 in bitwise context
3. Results in value 14 (0 | 4 | 2 | 8) without any indication of the
   error

This creates invisible configuration errors that are difficult to debug.

Proposed Change

Proposal: Add Diagnostics for Undefined Constants

We propose emitting diagnostics when undefined constants are encountered
in configuration files:

During startup (php.ini parsing):

 PHP: Use of undefined constant NAME_OF_CONSTANT - assumed 

'NAME_OF_CONSTANT' (this will throw an Error in a future version of PHP)

During runtime (parse_ini_file/string):

 PHP Warning: Use of undefined constant NAME_OF_CONSTANT - assumed 

'NAME_OF_CONSTANT' (this will throw an Error in a future version of PHP) in
filename on line X

This makes configuration errors visible and paves the way for future
strict handling.

Message Severity Discussion

The proposed warning message and severity mirror the PHP 7.2 approach
for undefined constants in scripts:

 Warning: Use of undefined constant UNDEFINED_CONSTANT - assumed 

'UNDEFINED_CONSTANT' (this will throw an Error in a future version of PHP)

Alternative severity levels could be considered:

| Severity | Wording | Intent |
|--------------|--------------|---------------------|
| E_DEPRECATED | "may throw" | Softer transition |
| E_WARNING | "will throw" | Clear future intent |
| E_NOTICE | "will throw" | Less intrusive |

The PHP 7.2 precedent suggests E_WARNING is appropriate for this level
of issue.

Benefits

• Early detection: Configuration errors become visible immediately
• Consistency: Aligns ini parsing behavior with PHP 8 language
  semantics
• Fail-fast: Helps users identify and fix configuration mistakes sooner
• Future-proof: Enables eventual strict mode matching PHP script
  behavior

Implementation Notes

The change would be implemented in zend_ini_get_constant() by adding
diagnostics when constant resolution fails. The current ini_error()
function uses ZEND_COLD (compiler hint for infrequently executed
code), which remains appropriate since undefined constants should be
rare in production configurations.

This infrastructure would also support a future transition to throwing
Errors, though the error handling mechanism might need adjustment at
that time.

• Note: This section is preliminary and subject to implementation

•   details.
  

References

PHP Manual Pages

a.) parse_ini_file()
https://www.php.net/manual/en/function.parse-ini-file.php
b.) The Configuration File
https://www.php.net/manual/en/configuration.file.php
c.) Core Predefined Constants
https://www.php.net/manual/en/reserved.constants.php#reserved.constants.core

3v4l.org PHP Codes

d.) https://3v4l.org/7PA3u Undefined constant
e.) https://3v4l.org/vC6mg Unsupported operand types