[PHP-DEV] [RFC] Display Function Arguments in Errors

Calvin_Buckley · April 2, 2026, 6:39pm

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.

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

Tim_Dusterhus · April 2, 2026, 8:06pm

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

Calvin_Buckley · April 7, 2026, 3:23pm

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.

PHP: 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 · April 8, 2026, 10:08pm

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.

PHP: 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 · April 10, 2026, 8:38pm

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 · April 15, 2026, 8:09pm

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_Dusterhus · April 15, 2026, 8:35pm

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 · April 15, 2026, 9:57pm

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 · April 16, 2026, 10:05am

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.

Calvin_Buckley · April 27, 2026, 4:05pm

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.

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