I've made this suggestion as issue #9778 (
https://github.com/php/php-src/issues/9778) and PR # 9789 (
https://github.com/php/php-src/pull/9789), but have been invited by
@damianwadley to bring it to the mailing list.
The Scorecards GitHub Action basically keeps an eye on a repo's security
posture
On 20.10.2022 at 19:03, Rowan Tommins wrote:
> On 20/10/2022 17:48, David Rodrigues wrote:
>
>> Regarding this, in case you're literally saying that internally "fn()"
>> turns into a common "function", and getting back to the main topic,
>> would it be possible to do the same with compact()?
>>
>>
On 28 May 2022, at 03:36, Craig Francis wrote:
> On 8 Apr 2022, at 18:34, Craig Francis wrote:
>> I've written a new draft RFC to address the NULL coercion problems:
>> https://wiki.php.net/rfc/null_coercion_consistency
>
>
> I give up.
For everyone affected by this... Rector has a "solution
On 20/10/2022 17:48, David Rodrigues wrote:
Regarding this, in case you're literally saying that internally "fn()"
turns into a common "function", and getting back to the main topic,
would it be possible to do the same with compact()?
fn() => compact('dummy')
turns into:
fn() => [ 'dummy' => $
> $foo = fn() => [$a, compact('a', 'b')];
> is essentially compiled to:
> $foo = function (use $a) { return [$a, compact('a', 'b')] };
Regarding this, in case you're literally saying that internally "fn()"
turns into a common "function", and getting back to the main topic, would
it be possible to
Hello Internals,
PHP suffers from several issues related to timeout and signal handling,
especially when built with ZTS enabled.
1. The current implementation of timeouts on UNIX builds seems
"fundamentally incompatible with ZTS" (
https://bugs.php.net/bug.php?id=79464#1589205685) and more anecdo
On Wed, 19 Oct 2022 at 19:11, Tim Düsterhus wrote:
>
> While the behavior would in fact change, it would not introduce a
> "security issue" if this what you were hinting at.
No, just that it would break in production, and then have to be fixed
after a live site was already affecting end-users.
>
On 19/10/2022 18:04, David Rodrigues wrote:
It seems to me to be a reasonable problem and one that needs attention, as
the message is not that "compact cannot be used here", but that "the
variable does not exist".
I'd just like to point out that the error message here is 100% correct:
there is
>
> How would you like it to work, if you pass a variable name variable to
> compact then?
> $x = 123;
> $name = 'x';
> (fn () => compact($name))();
>
Although it is difficult to make it work in general (of course), there is the
specific case of names given as literal strings, as in the exampl
