[RFC] Display Function Arguments in Errors

Gina P. Banyard

174 days ago

On Wednesday, 11 March 2026 at 15:58, Calvin Buckley <calvin@cmpct.info> wrote:

> Hi internals,
>
> Based on the feedback I had from my proposal for function arguments in
> errors last week, I'd like to introduce an RFC for it. Please let me
> know what you think and please raise any possible issues.
>
> https://wiki.php.net/rfc/display_error_function_args
>
> Regards,
> Calvin

I'm looking forward to this RFC, as normalizing the behaviour of diagnostics by removing the various docref functions is something I proposed back in 2019. [1]
And I do think that we should remove the parameter versions of the docref functions as the behaviour of them if this is accepted seems hard to determine.

Best regards,

Gina P. Banyard

[1] https://github.com/php/php-src/pull/4254

Tim Düsterhus

174 days ago

Hi

On 3/11/26 16:55, Calvin Buckley wrote:

> Based on the feedback I had from my proposal for function arguments in
> errors last week, I'd like to introduce an RFC for it. Please let me
> know what you think and please raise any possible issues.
>
> https://wiki.php.net/rfc/display_error_function_args

Thank you for the RFC. I have the following comments:

1.

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.

2.

As for the naming of the bikeshed, I suggest `error_ignore_args` for
consistency with `zend.exception_ignore_args`.

3.

For the voting options: You need to define a tie-breaker for the
secondary votes.

Best regards
Tim Düsterhus

Andrey Andreev

173 days ago

Hi,

On Wed, Mar 11, 2026 at 8:38 PM Tim Düsterhus <tim@bastelstu.be> 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.

Calvin Buckley

173 days ago

On Mar 11, 2026, at 7:06 PM, Andrey Andreev <narf@devilix.net> wrote:

>
> Hi,
>
> On Wed, Mar 11, 2026 at 8:38 PM Tim Düsterhus <tim@bastelstu.be> 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.

This is something I'm also concerned about, but I feel the cat is
already out of the bag with backtraces in exceptions providing the same
parameter information. PHP and the library ecosystem seem to be adopting
the sensitive parameter attribute, so my hope is that applications also
start adopting it.

Andrey Andreev

168 days ago

On Thu, Mar 12, 2026 at 5:59 PM Calvin Buckley <calvin@cmpct.info> wrote:

> On Mar 11, 2026, at 7:06 PM, Andrey Andreev <narf@devilix.net> wrote:
>
> >
> > 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.
>
> This is something I'm also concerned about, but I feel the cat is
> already out of the bag with backtraces in exceptions providing the same
> parameter information. PHP and the library ecosystem seem to be adopting
> the sensitive parameter attribute, so my hope is that applications also
> start adopting it.

On one hand, it's true that the cat is already out of the bag. On the
other, that's been the case since at least the days of PHP 4 and related
effort since has been to limit the danger. This would be a first in the
other direction.

Semi-random idea: what if it was a declare statement instead of an INI?
That would have multiple benefits:
- Can limit the exposure to particular scripts rather than globally
- Easy to spot during code reviews and therefore little danger of negligent
leaks
- Potential to consolidate backtraces under the same umbrella and
eventually retire zend.exception_ignore_args

Cheers,
Andrey.

Calvin Buckley

173 days ago

On Mar 11, 2026, at 3:35 PM, Tim Düsterhus <tim@bastelstu.be> wrote:

>
> Hi
>
> On 3/11/26 16:55, Calvin Buckley wrote:
>> Based on the feedback I had from my proposal for function arguments in
>> errors last week, I'd like to introduce an RFC for it. Please let me
>> know what you think and please raise any possible issues.
>> https://wiki.php.net/rfc/display_error_function_args
>
> Thank you for the RFC. I have the following comments:
>
> 1.
>
> 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'm adding this to the ecosystem impact section.

> 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.

I do recognize that PHP has been trending towards fewer knobs;
unfortunately, I don't see a better way other than adding a new
knob.

> 2.
>
> As for the naming of the bikeshed, I suggest `error_ignore_args` for consistency with `zend.exception_ignore_args`.

I'm not attached to the name; if others think this sounds good, I'll
adjust the RFC and PR.

> 3.
>
> For the voting options: You need to define a tie-breaker for the secondary votes.

I might be a little dense here; I see tie-breakers mentioned in
feature-proposals, but I don't see any guidance on how to include them
in an RFC. The other RFCs I've been skimming don't seem to mention them
either.

Larry Garfield

173 days ago

On Thu, Mar 12, 2026, at 10:53 AM, Calvin Buckley wrote:

> On Mar 11, 2026, at 3:35 PM, Tim Düsterhus <tim@bastelstu.be> wrote:

>> 3.
>>
>> For the voting options: You need to define a tie-breaker for the secondary votes.
>
> I might be a little dense here; I see tie-breakers mentioned in
> feature-proposals, but I don't see any guidance on how to include them
> in an RFC. The other RFCs I've been skimming don't seem to mention them
> either.

Just put something like "in case of a tie, the default will be 1" above that voting widget.  (Or 0 if you want to go that way.)  Same for the other one.

Few RFCs have secondary votes, so you won't see it very often.  And they don't always mention a tie breaker, even though they arguably should.

--Larry Garfield

Calvin Buckley

168 days ago

On Mar 12, 2026, at 2:54 PM, Larry Garfield <larry@garfieldtech.com> wrote:

>
> On Thu, Mar 12, 2026, at 10:53 AM, Calvin Buckley wrote:
>> On Mar 11, 2026, at 3:35 PM, Tim Düsterhus <tim@bastelstu.be> wrote:
>
>>> 3.
>>>
>>> For the voting options: You need to define a tie-breaker for the secondary votes.
>>
>> I might be a little dense here; I see tie-breakers mentioned in
>> feature-proposals, but I don't see any guidance on how to include them
>> in an RFC. The other RFCs I've been skimming don't seem to mention them
>> either.
>
> Just put something like "in case of a tie, the default will be 1" above that voting widget.  (Or 0 if you want to go that way.)  Same for the other one.
>
> Few RFCs have secondary votes, so you won't see it very often.  And they don't always mention a tie breaker, even though they arguably should.
>
> --Larry Garfield

Sorry for the late response, I've added tiebreakers to the vote section.

Tim Düsterhus

168 days ago

Hi

On 3/16/26 20:04, Calvin Buckley wrote:

> Sorry for the late response, I've added tiebreakers to the vote section.

Thank you, that looks good to me.

With the latest changes for the tie-breakers and the impact section I
don't have any other comment.

Naming of the INI (i.e. my suggestion for "error_ignore_args") still is
open. Does anyone except me have opinion there?

Best regards
Tim Düsterhus

Calvin Buckley

155 days ago

On Mar 11, 2026, at 12:55 PM, Calvin Buckley <calvin@cmpct.info> wrote:

>
> Hi internals,
>
> Based on the feedback I had from my proposal for function arguments in
> errors last week, I'd like to introduce an RFC for it. Please let me
> know what you think and please raise any possible issues.
>
> https://wiki.php.net/rfc/display_error_function_args
>
> Regards,
> Calvin

If I don't hear any additional feedback, I think I'll open this for
voting at the end of the week.

Tim Düsterhus

155 days ago

Hi

Am 2026-03-30 16:40, schrieb Calvin Buckley:

> If I don't hear any additional feedback, I think I'll open this for
> voting at the end of the week.

I've looked once more into my “naming remark” and realized that the
`display_` prefix might actually be misleading (instead of “just”
inconsistent) when compared to `display_errors` or
`display_startup_errors`, because `display_error_function_args` does not
control whether the arguments are *displayed*. It also controls whether
or not the arguments are visible to a registered error_handler, which is
quite different from just suppressing them from public display as done
by `display_errors`.

My suggestion of `error_ignore_args` thus still stands and I would
likely vote against the RFC with the current naming (despite being in
favor of the feature itself).

Best regards
Tim Düsterhus

Calvin Buckley

155 days ago

On Mar 30, 2026, at 12:24 PM, Tim Düsterhus <tim@bastelstu.be> wrote:

>
> Hi
>
> Am 2026-03-30 16:40, schrieb Calvin Buckley:
>> If I don't hear any additional feedback, I think I'll open this for
>> voting at the end of the week.
>
> I've looked once more into my “naming remark” and realized that the `display_` prefix might actually be misleading (instead of “just” inconsistent) when compared to `display_errors` or `display_startup_errors`, because `display_error_function_args` does not control whether the arguments are *displayed*. It also controls whether or not the arguments are visible to a registered error_handler, which is quite different from just suppressing them from public display as done by `display_errors`.
>
> My suggestion of `error_ignore_args` thus still stands and I would likely vote against the RFC with the current naming (despite being in favor of the feature itself).
>
> Best regards
> Tim Düsterhus

I can rename this in the RFC since no one else had any other suggestions.
I'm not attached to any name for the INI option myself.

Calvin Buckley

154 days ago

On Mar 30, 2026, at 12:24 PM, Tim Düsterhus <tim@bastelstu.be> wrote:

>
> Hi
>
> Am 2026-03-30 16:40, schrieb Calvin Buckley:
>> If I don't hear any additional feedback, I think I'll open this for
>> voting at the end of the week.
>
> I've looked once more into my “naming remark” and realized that the `display_` prefix might actually be misleading (instead of “just” inconsistent) when compared to `display_errors` or `display_startup_errors`, because `display_error_function_args` does not control whether the arguments are *displayed*. It also controls whether or not the arguments are visible to a registered error_handler, which is quite different from just suppressing them from public display as done by `display_errors`.
>
> My suggestion of `error_ignore_args` thus still stands and I would likely vote against the RFC with the current naming (despite being in favor of the feature itself).
>
> Best regards
> Tim Düsterhus

I've renamed the INI option per your suggestion. This does invert the
semantics (matching the one for exceptions), so I took some care when
editing. I'll update the PR accordingly soon.

Tim Düsterhus

154 days ago

Hi

Am 2026-03-30 21:00, schrieb Calvin Buckley:

> I've renamed the INI option per your suggestion. This does invert the
> semantics (matching the one for exceptions), so I took some care when
> editing. I'll update the PR accordingly soon.

I've checked the diff and noticed that you did not adjust the tie
breaker for the “Default value for error_ignore_args” vote (it still
favors `1`). Was this intentional or an oversight?

Other than that the RFC looks good to me. Thank you!

Best regards
Tim Düsterhus

Calvin Buckley

154 days ago

On Mar 31, 2026, at 6:04 AM, Tim Düsterhus <tim@bastelstu.be> wrote:

>
> Hi
>
> Am 2026-03-30 21:00, schrieb Calvin Buckley:
>> I've renamed the INI option per your suggestion. This does invert the
>> semantics (matching the one for exceptions), so I took some care when
>> editing. I'll update the PR accordingly soon.
>
> I've checked the diff and noticed that you did not adjust the tie breaker for the “Default value for error_ignore_args” vote (it still favors `1`). Was this intentional or an oversight?
>
> Other than that the RFC looks good to me. Thank you!
>
> Best regards
> Tim Düsterhus

I've corrected this.

Calvin Buckley

152 days ago

On Mar 30, 2026, at 11:40 AM, Calvin Buckley <calvin@cmpct.info> wrote:

>
> On Mar 11, 2026, at 12:55 PM, Calvin Buckley <calvin@cmpct.info> wrote:
>>
>> Hi internals,
>>
>> Based on the feedback I had from my proposal for function arguments in
>> errors last week, I'd like to introduce an RFC for it. Please let me
>> know what you think and please raise any possible issues.
>>
>> https://wiki.php.net/rfc/display_error_function_args
>>
>> Regards,
>> Calvin
>
> If I don't hear any additional feedback, I think I'll open this for
> voting at the end of the week.

I've changed the name again to try to address everyone's concerns;
because of this, I'll delay the voting by a week, especially since
it's a holiday on when I had originally intended to do so anyways.
Feedback would be appreciated.

Calvin Buckley

143 days ago

On Apr 2, 2026, at 3:39 PM, Calvin Buckley <calvin@cmpct.info> wrote:

>
> I've changed the name again to try to address everyone's concerns;
> because of this, I'll delay the voting by a week, especially since
> it's a holiday on when I had originally intended to do so anyways.
> Feedback would be appreciated.

I've updated the RFC again to put benchmarks for perf impact (as was
mentioned on the list); for the sake of a minor change cooldown period,
I'll give it another week to start voting and allow for discussion.

Andrey Andreev

138 days ago

Hi,

My last comment (https://externals.io/message/130290#130377) was not
addressed, and I still have two major issues with the RFC as is:
- It is clearly aiming for default of 1 and unreasonably expects all
codebases to be (meticulously) updated with SensitiveParameter attribute -
that is "opt-in security" and not secure by default
- While a "risk of untagged PII in logs" is mentioned, it is done so with
language that severely downplays the issue

Given these, and that the word "security" isn't even mentioned in the RFC,
I don't believe that the security impact is taken seriously at all.

Cheers,
Andrey.

Tim Düsterhus

138 days ago

Hi

Am 2026-04-15 22:09, schrieb Andrey Andreev:

> - It is clearly aiming for default of 1 and unreasonably expects all
> codebases to be (meticulously) updated with SensitiveParameter
> attribute -
> that is "opt-in security" and not secure by default

There is no stack trace here, which means that the only functions that
are affected by this RFC are native functions. Userland functions
calling `trigger_error()` don't show the function name. All the native
functions in php-src that handle sensitive inputs have been adapted
right with the introduction of the #[\SensitiveParameter] attribute in
PHP 8.2 - and if some are missing, I would consider that a pre-existing
bug that needs fixing.

And even if this wasn't the case, the ecosystem has widely adopted the
attribute in the 4 years since its introduction, which was easily
possible since attributes are fully backwards and forwards compatible
with all PHP versions (including PHP versions that do not yet support
attributes).

Best regards
Tim Düsterhus

Calvin Buckley

138 days ago

On Apr 15, 2026, at 5:35 PM, Tim Düsterhus <tim@bastelstu.be> wrote:

>
> Hi
>
> Am 2026-04-15 22:09, schrieb Andrey Andreev:
>> - It is clearly aiming for default of 1 and unreasonably expects all
>> codebases to be (meticulously) updated with SensitiveParameter attribute -
>> that is "opt-in security" and not secure by default
>
> There is no stack trace here, which means that the only functions that are affected by this RFC are native functions. Userland functions calling `trigger_error()` don't show the function name. All the native functions in php-src that handle sensitive inputs have been adapted right with the introduction of the #[\SensitiveParameter] attribute in PHP 8.2 - and if some are missing, I would consider that a pre-existing bug that needs fixing.
>
> And even if this wasn't the case, the ecosystem has widely adopted the attribute in the 4 years since its introduction, which was easily possible since attributes are fully backwards and forwards compatible with all PHP versions (including PHP versions that do not yet support attributes).
>
> Best regards
> Tim Düsterhus

I think I'll edit the RFC to clarify this.

Andrey Andreev

138 days ago

Fair enough, thanks for the clarification, although then this initial
response makes little sense in context:

On Thu, Mar 12, 2026 at 5:59 PM Calvin Buckley <calvin@cmpct.info> wrote:

> This is something I'm also concerned about, but I feel the cat is
> already out of the bag with backtraces in exceptions providing the same
> parameter information. PHP and the library ecosystem seem to be adopting
> the sensitive parameter attribute, so my hope is that applications also
> start adopting it.

Also, you can only mark a parameter as sensitive if you *know* that it
contains something sensitive, so I'm assuming that only covers passwords,
private keys, etc. However, almost any string parameter can contain
sensitive data and that's where the danger is - all applications handling
PII will be at risk of inadvertently leaking data through logs.

Cheers,
Andrey.

Derick Rethans

154 days ago

On Wed, 11 Mar 2026, Calvin Buckley wrote:

> Based on the feedback I had from my proposal for function arguments in
> errors last week, I'd like to introduce an RFC for it. Please let me
> know what you think and please raise any possible issues.
>
> https://wiki.php.net/rfc/display_error_function_args

| Add a error_ignore_args, which potentially defaults to “0”. This is
| made an INI option, as some users may want to disable the feature by
| enabling this option, at least for production (e.g. risks of untagged
| PII in logs, size of logs, format compatibility with older versions of
| PHP).

I'm generally not in favour of new ini settings. I also don't think this
is going to help a lot, as many people will likely not change the
default.

But, I am especially not keen on "negative names". Names that include
"ignore" or "disable" for example. If you must have an ini setting, it
ought to be something like "include_error_args" (defaulting to "0", I
suspect).

The confusion in
https://github.com/php/php-src/pull/12276#pullrequestreview-4035216287
also explains why I feel this.

cheers,
Derick

--
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support

mastodon: @derickr@phpc.social @xdebug@phpc.social

Calvin Buckley

154 days ago

On Mar 31, 2026, at 6:53 AM, Derick Rethans <derick@php.net> wrote:

>
> On Wed, 11 Mar 2026, Calvin Buckley wrote:
>
>> Based on the feedback I had from my proposal for function arguments in
>> errors last week, I'd like to introduce an RFC for it. Please let me
>> know what you think and please raise any possible issues.
>>
>> https://wiki.php.net/rfc/display_error_function_args
>
> | Add a error_ignore_args, which potentially defaults to “0”. This is
> | made an INI option, as some users may want to disable the feature by
> | enabling this option, at least for production (e.g. risks of untagged
> | PII in logs, size of logs, format compatibility with older versions of
> | PHP).
>
> I'm generally not in favour of new ini settings. I also don't think this
> is going to help a lot, as many people will likely not change the
> default.
>
> But, I am especially not keen on "negative names". Names that include
> "ignore" or "disable" for example. If you must have an ini setting, it
> ought to be something like "include_error_args" (defaulting to "0", I
> suspect).
>
> The confusion in
> https://github.com/php/php-src/pull/12276#pullrequestreview-4035216287
> also explains why I feel this.
>
> cheers,
> Derick
>
> --
> https://derickrethans.nl | https://xdebug.org | https://dram.io
>
> Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support
>
> mastodon: @derickr@phpc.social @xdebug@phpc.social

Tim, would this name be OK? I also have a preference towards a non-inverted name (it was more overhead to keep track of it), but I do see wanting it consistent.

Tim Düsterhus

151 days ago

Hi

Am 2026-03-31 15:57, schrieb Calvin Buckley:

> Tim, would this name be OK? I also have a preference towards a
> non-inverted name (it was more overhead to keep track of it), but I do
> see wanting it consistent.

I *prefer* consistency for discoverability, but I agree that “inverted”
INIs are confusing. No strong opinion either way and definitely not a
deal breaker for me.

Best regards
Tim Düsterhus

Matthew Weier O'Phinney

152 days ago

On Wed, Mar 11, 2026 at 10:56 AM Calvin Buckley <calvin@cmpct.info> wrote:

> Based on the feedback I had from my proposal for function arguments in
> errors last week, I'd like to introduce an RFC for it. Please let me
> know what you think and please raise any possible issues.
>
> https://wiki.php.net/rfc/display_error_function_args
>

Have you done any benchmarking on this? What is the performance impact when
it is enabled versus disabled? That information will be useful if this
passes so that users can understand not just the security impact of having
this information reported in logs, but the performance impact.

--
Matthew Weier O'Phinney
mweierophinney@gmail.com
https://mwop.net/
he/him

Calvin Buckley

152 days ago

On Apr 2, 2026, at 11:25 AM, Matthew Weier O'Phinney <mweierophinney@gmail.com> wrote:

>
> On Wed, Mar 11, 2026 at 10:56 AM Calvin Buckley <calvin@cmpct.info> wrote:
> Based on the feedback I had from my proposal for function arguments in
> errors last week, I'd like to introduce an RFC for it. Please let me
> know what you think and please raise any possible issues.
>
> https://wiki.php.net/rfc/display_error_function_args
>
> Have you done any benchmarking on this? What is the performance impact when it is enabled versus disabled? That information will be useful if this passes so that users can understand not just the security impact of having this information reported in logs, but the performance impact.
>
> --
> Matthew Weier O'Phinney
> mweierophinney@gmail.com
> https://mwop.net/
> he/him

I haven't yet. I suppose the usual benchmark suite PHP runs might not be interesting for this seeing as they probably shouldn't be writing to the error log...

Calvin Buckley

147 days ago

On Apr 2, 2026, at 11:25 AM, Matthew Weier O'Phinney <mweierophinney@gmail.com> wrote:

>
> On Wed, Mar 11, 2026 at 10:56 AM Calvin Buckley <calvin@cmpct.info> wrote:
> Based on the feedback I had from my proposal for function arguments in
> errors last week, I'd like to introduce an RFC for it. Please let me
> know what you think and please raise any possible issues.
>
> https://wiki.php.net/rfc/display_error_function_args
>
> Have you done any benchmarking on this? What is the performance impact when it is enabled versus disabled? That information will be useful if this passes so that users can understand not just the security impact of having this information reported in logs, but the performance impact.
>
> --
> Matthew Weier O'Phinney
> mweierophinney@gmail.com
> https://mwop.net/
> he/him

FWIW, I actually did try running benchmark/benchmark.php. The difference is pretty much margin of error (somehow fewer instructions in some cases?), but I also don't expect to see much of any docrefs triggered in it either. For the sake of completeness:

Without:
{
"Zend\/bench.php": {
"instructions": "1979721332"
},
"Zend\/bench.php JIT": {
"instructions": "589555739"
},
"Symfony Demo 2.2.3": {
"instructions": "87285017"
},
"Symfony Demo 2.2.3 JIT": {
"instructions": "90024058"
},
"Wordpress 6.2": {
"instructions": "244605957"
},
"Wordpress 6.2 JIT": {
"instructions": "211892436"
}
}
With:
{
"Zend\/bench.php": {
"instructions": "1979721328"
},
"Zend\/bench.php JIT": {
"instructions": "589555784"
},
"Symfony Demo 2.2.3": {
"instructions": "87285011"
},
"Symfony Demo 2.2.3 JIT": {
"instructions": "90023734"
},
"Wordpress 6.2": {
"instructions": "244606014"
},
"Wordpress 6.2 JIT": {
"instructions": "211892519"
}
}

You can try it yourself with this patch (set error_include_args as needed):

diff --git a/benchmark/benchmark.php b/benchmark/benchmark.php
index 0c2ac4c6010..6377c3ceb37 100644
--- a/benchmark/benchmark.php
+++ b/benchmark/benchmark.php
@@ -79,7 +79,8 @@ function runWordpress(bool $jit): array {
/* FIXME: It might be better to use a stable version of PHP for this command because we can't
* easily alter the phar file */
runPhpCommand([
-        '-d error_reporting=0',
+        '-d error_reporting=22527',
+        '-d error_include_args=1',
'wp-cli.phar',
'core',
'install',
@@ -122,6 +123,8 @@ function runValgrindPhpCgiCommand(
'--',
$phpCgi,
'-T' . ($warmup ? $warmup . ',' : '') . $repeat,
+        '-d error_reporting=22527',
+        '-d error_include_args=1',
'-d max_execution_time=0',
'-d opcache.enable=1',
'-d opcache.jit=' . ($jit ? 'tracing' : 'disable'),

I'm working on something that triggers a lot of docrefs in a hot loop, but I also don't know how interesting that would be seeing as if you're getting thousands of docref-triggered messages a second, your program probably has an issue.

Calvin Buckley

145 days ago

On Apr 2, 2026, at 11:25 AM, Matthew Weier O'Phinney <mweierophinney@gmail.com> wrote:

>
> On Wed, Mar 11, 2026 at 10:56 AM Calvin Buckley <calvin@cmpct.info> wrote:
> Based on the feedback I had from my proposal for function arguments in
> errors last week, I'd like to introduce an RFC for it. Please let me
> know what you think and please raise any possible issues.
>
> https://wiki.php.net/rfc/display_error_function_args
>
> Have you done any benchmarking on this? What is the performance impact when it is enabled versus disabled? That information will be useful if this passes so that users can understand not just the security impact of having this information reported in logs, but the performance impact.
>
> --
> Matthew Weier O'Phinney
> mweierophinney@gmail.com
> https://mwop.net/
> he/him

I've been doing a very stupid benchmark (let's call it Lhogstones):

<?php

/* -d error_include_args=X -d display_errors=0 -d error_log=/tmp/test */

$iter = isset($argv[1]) ? intval($argv[1]) : 10000;
$start = hrtime(true);
for ($i = 0; $i < $iter; $i++) {
hex2bin("ABC"); /* or like unlink("/") for something that does more */
}
$end = hrtime(true);
$total_ns = $end - $start;
$total = $total_ns / 1_000_000_000;

echo "Finished $iter iterations in $total sec\n";

?>

On an M1 Pro:

Iterations  With         Without
10000       0.025276917  0.016741333
100000      0.189566666  0.123559584
1000000     1.798127917  1.146331917
10000000    18.1332335   11.267384125

There is an impact from turning it on, but my feeling is that it would be pretty minor. If your code has a lot of warnings/errors, then my feeling is that errors should be fixed before you can or should measure performance. Calling php_error_docref in a tight loop isn't really normal behaviour. So, while there is an impact, I also don't think it matters too much. If people think the impact *does* matter and is significant, then I could add a vote to separate the production vs. development INI value.

Calvin Buckley

127 days ago

On Mar 11, 2026, at 12:55 PM, Calvin Buckley <calvin@cmpct.info> wrote:

>
> Hi internals,
>
> Based on the feedback I had from my proposal for function arguments in
> errors last week, I'd like to introduce an RFC for it. Please let me
> know what you think and please raise any possible issues.
>
> https://wiki.php.net/rfc/display_error_function_args
>
> Regards,
> Calvin

Per feature-proposals, this is an Intent to Vote message.

I intend to start the vote on Friday, around the evening in Europe.