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