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
