Hi, On Wed, Mar 11, 2026 at 8:38 PM Tim Düsterhus <[email protected]> wrote:
> I believe there is almost never “No Impact” to the ecosystem. In fact > the RFC partly acknowledges it in the “Backward Incompatible Changes” > section. Even if the corresponding sub-vote to default to 1 doesn't > pass, code needs to be prepared for someone to set it to 1 themselves. > This includes off-the-shelf software (such as WordPress, or Drupal, or > whatever). > > I have the following two suggestions (that follow pretty naturally, but > are nevertheless an impact that should be spelled out): > > a) Custom error handlers (set_error_handlers()) need to be prepared for > the error message format to change. Even though we don't make any > guarantees about error messages themselves, the existing format with > “function name first” is reasonably structured for automated parsing > (e.g. using a regular expression). This also includes error tracking > tools that try to group error messages by function or similar. > > b) System administrators have one more INI setting to deal with and need > to make a decision. Previous versions of the RFC template had an > explicit “INI setting” section, but given it's so rare we add new INI > settings these days, it has been removed from the template. For the few > that still add one, properly discussing the consequences still is valuable. These are all excellent points. I want to add one more side-effect that feels discounted: PII and other sensitive data leaking through logs. Partly what the INI setting is supposed to address, but IMO it only does so on paper. I have dealt with that issue many times, and developers tend to either not take it seriously or propose naive patchwork solutions such as blacklisting patterns in already produced logs. Plus, there's an inherent temptation to temporarily enable such settings for debugging purposes, not realizing the act itself represents a data leak and it is permanent. If this is a serious problem without args values being present today, imagine the amplification effect from this addition. With that being said, I also know the pain of having to deal with borderline useless error messages. The proposal isn't without merit, but I'd look for alternative approaches that don't create security headaches. Cheers, Andrey.
