Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128781
Content-Type: multipart/alternative;
 boundary="----sinikael-?=_1-17596688999030.18495869788146002"
Message-ID: <1759668599422.2126186334.2604999201@yahoo.de>
To: internals@lists.php.net
Subject: [PHP-DEV] Deprecate Undefined Constant Usage in php.ini Files (GH-20060)
Date: Sun, 05 Oct 2025 12:54:59 +0000
User-Agent: Vivaldi Mail/7.6.3797.56
Precedence: list
MIME-Version: 1.0
References: <1759668599422.2126186334.2604999201.ref@yahoo.de>
From: hanskrentel@yahoo.de (Hans Krentel)

------sinikael-?=_1-17596688999030.18495869788146002
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

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
------sinikael-?=_1-17596688999030.18495869788146002
Content-Type: text/html; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

<html><head></head><body><div style=""><pre style="">Hello list,</pre><pre 
style="">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.
<br>Best,<br><br>-- hakre<br><br><br>## Deprecate Undefined Constant Usage 
in php.ini Files<br><br>The php.ini file parser (as used by 
`parse_ini_file()`) supports<br>constant resolution, including core 
predefined constants. However, the<br>current behavior with undefined 
constants is inconsistent with PHP 8's<br>strict handling of undefined 
constants in regular PHP code.<br><br>### Problem Statement<br><br>#### 
Current Inconsistent Behavior<br><br>In PHP 8 scripts, undefined constants 
trigger immediate fatal errors:<br><br>    &lt;?php<br>    $var = X_ERROR; 
// Fatal error: Undefined constant "X_ERROR"<br><br>However, in php.ini 
files, undefined constants are silently handled<br>using PHP 4-era 
semantics:<br><br>    [PHP]<br>    error_reporting = 
X_ERROR|E_WARNING|E_PARSE|E_NOTICE<br><br>This silently:<br><br>1. Converts 
`X_ERROR` to string `"X_ERROR"`<br>2. Converts that string to integer `0` 
in bitwise context<br>3. Results in value `14` (0 | 4 | 2 | 8) without any 
indication of the<br>   error<br><br>This creates invisible configuration 
errors that are difficult to debug.<br><br>### Proposed Change<br><br>#### 
Proposal: Add Diagnostics for Undefined Constants<br><br>We propose 
emitting diagnostics when undefined constants are encountered<br>in 
configuration files:<br><br>**During startup (php.ini 
parsing):**<br><br><br>    PHP: Use of undefined constant NAME_OF_CONSTANT 
- assumed 'NAME_OF_CONSTANT' (this will throw an Error in a future version 
of PHP)<br><br><br>**During runtime (parse_ini_file/string):**<br><br><br>  
  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<br><br><br>This makes configuration errors visible and 
paves the way for future<br>strict handling.<br><br>### Message Severity 
Discussion<br><br>The proposed warning message and severity mirror the PHP 
7.2 approach<br>for undefined constants in scripts:<br><br><br>    Warning: 
Use of undefined constant UNDEFINED_CONSTANT - assumed 'UNDEFINED_CONSTANT' 
(this will throw an Error in a future version of 
PHP)<br><br><br>Alternative severity levels could be considered:<br><br>| 
Severity     | Wording      | Intent              
|<br>|--------------|--------------|---------------------|<br>| 
E_DEPRECATED | "may throw"  | Softer transition   |<br>| E_WARNING    | 
"will throw" | Clear future intent |<br>| E_NOTICE     | "will throw" | 
Less intrusive      |<br><br>The PHP 7.2 precedent suggests E_WARNING is 
appropriate for this level<br>of issue.<br><br>### Benefits<br><br>- Early 
detection: Configuration errors become visible immediately<br>- 
Consistency: Aligns ini parsing behavior with PHP 8 language<br>  
semantics<br>- Fail-fast: Helps users identify and fix configuration 
mistakes sooner<br>- Future-proof: Enables eventual strict mode matching 
PHP script<br>  behavior<br><br>### Implementation Notes<br><br>The change 
would be implemented in `zend_ini_get_constant()` by adding<br>diagnostics 
when constant resolution fails. The current `ini_error()`<br>function uses 
`ZEND_COLD` (compiler hint for infrequently executed<br>code), which 
remains appropriate since undefined constants should be<br>rare in 
production configurations.<br><br>This infrastructure would also support a 
future transition to throwing<br>Errors, though the error handling 
mechanism might need adjustment at<br>that time.<br><br>* Note: This 
section is preliminary and subject to implementation<br>*       
details.<br><br>### References<br><br>#### PHP Manual Pages<br><br>a.) 
parse_ini_file() 
&lt;https://www.php.net/manual/en/function.parse-ini-file.php&gt;<br>b.) 
The Configuration File 
&lt;https://www.php.net/manual/en/configuration.file.php&gt;<br>c.) Core 
Predefined Constants 
&lt;https://www.php.net/manual/en/reserved.constants.php#reserved.constants.core&gt;<br><br>#### 
3v4l.org PHP Codes<br><br>d.) https://3v4l.org/7PA3u Undefined 
constant<br>e.) https://3v4l.org/vC6mg Unsupported operand types<font 
color="#080808" face="JetBrains Mono, monospace"><span style="font-size: 
11.3pt;"><br></span></font></pre></div><span 
class="viv-signature-below"></span></body></html>
------sinikael-?=_1-17596688999030.18495869788146002--