> On Dec 1, 2020, at 8:57 AM, Nikita Popov wrote:
>
> I've put up an RFC to make the handling of "null" arguments consistent
> between internal and user-defined functions:
>
> https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_arg
>
On Tue, Dec 1, 2020, at 8:57 AM, Nikita Popov wrote:
> Hi internals,
>
> I've put up an RFC to make the handling of "null" arguments consistent
> between internal and user-defined functions:
>
> https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_arg
>
> I started an informal discussion
Hi!
I'm referring to support for non-trivial expressions, aka blocks. Say, the
ability to split up a long expression by using a meaningful temporary
variable. Block support is sufficient to cover *most* switch use-cases,
obviating the need to introduce a new switch variant.
We could take a
On 01/12/2020 20:06, Stanislav Malyshev wrote:
is broken is a great illustration of that. PHP 8 makes it obvious
that the
cited code is incorrect.
But it's not incorrect. if is_file("abc\0") returns false, it's
correct - "abc\0" is not a correct filename, so I expect it to return
false. It
Hi!
yeah, you should think about external input *before* do anything with
it, always! if you pass a random path with NULL you did not do anything
to validate the input
Yes, and? is_file should be safe (as in, not exploding and breaking the
whole app) on any input (leaving typing discussion
Am 01.12.20 um 21:09 schrieb Stanislav Malyshev:
we are running error_reporting E_ALL for 17 years now and don't
distinct between notice / warning / error, it has to be fixed -
period
Surely you do. Your code continues to run after warning/notice but stops
after the error. It's impossible
Am 01.12.20 um 21:06 schrieb Stanislav Malyshev:
Hi!
First, assuming that a null byte in a file name *is* an error
condition, is
the PHP 8 behavior better than in PHP 7? I think the answer to this
one is
very clearly "yes". The above code snippet and the subtle way in which it
For me as
Hi!
we are running error_reporting E_ALL for 17 years now and don't
distinct between notice / warning / error, it has to be fixed -
period
Surely you do. Your code continues to run after warning/notice but stops
after the error. It's impossible to ignore that. Unless you have an
error handler
Hi!
First, assuming that a null byte in a file name *is* an error condition, is
the PHP 8 behavior better than in PHP 7? I think the answer to this one is
very clearly "yes". The above code snippet and the subtle way in which it
For me as a user that would be a very clear "no". Now if I have
Hi!
So why having is_file()/is_dir() throw a warning for the past 8 years
(since PHP 5.4) a non-issue? Because by that logic it shouldn't
Warning is a debugging functionality. Throwing is breaking the app and
stopping the whole process. There's a fundamental difference between the
two.
Hi!
In PHP 7, this returns FALSE:
php -r 'var_dump(is_file("ab\0c"));'
In PHP 8, the same code throws a ValueException. Problem is now that
I think this is a mistake. Exceptions should not be thrown on such
values, it only breeds boilerplate code (now you'd have to wrap each
call to is_*
On Tue, Dec 1, 2020 at 7:57 PM Larry Garfield
wrote:
> On Mon, Nov 30, 2020, at 9:09 AM, Nikita Popov wrote:
> > On Thu, Nov 26, 2020 at 5:39 PM David Rodrigues
> > wrote:
> >
> > > Hello!
> > >
> > > With PHP 8 we have match(), that is a switch strict expression-like.
> But
> > > strict is not
On Tue, Dec 1, 2020, 19:57 Larry Garfield wrote:
>
>
> Disagree. switch is a procedural logic flow control. match is an
> evaluation expression. Things like fallthrough do not belong there, as it
> mushes expressions together in weird ways. match is lovely because its
> logic flow is simple
On 01.12.2020 at 19:38, Aimeos | Norbert Sendetzky wrote:
> Am 01.12.20 um 19:23 schrieb G. P. B.:
>
>> So why having is_file()/is_dir() throw a warning for the past 8 years
>> (since PHP 5.4) a non-issue? Because by that logic it shouldn't
>> have been emitting warnings either.
>> Would it have
On Mon, Nov 30, 2020, at 9:09 AM, Nikita Popov wrote:
> On Thu, Nov 26, 2020 at 5:39 PM David Rodrigues
> wrote:
>
> > Hello!
> >
> > With PHP 8 we have match(), that is a switch strict expression-like. But
> > strict is not strict, and it could cause confusion because switch() and
> > match()
On Tue, 1 Dec 2020 at 18:35, Paul Crovella wrote:
> On Tue, Dec 1, 2020 at 10:23 AM G. P. B. wrote:
> >
> > On Tue, 1 Dec 2020 at 18:07, Paul Crovella
> wrote:
> >>
> >> On Tue, Dec 1, 2020 at 9:43 AM Christoph M. Becker
> wrote:
> >> >
> >> > On 01.12.2020 at 18:35, Aimeos | Norbert
Am 01.12.20 um 19:23 schrieb G. P. B.:
> So why having is_file()/is_dir() throw a warning for the past 8 years
> (since PHP 5.4) a non-issue? Because by that logic it shouldn't
> have been emitting warnings either.
> Would it have been fine if this would have been a TypeError as it was
>
On Tue, Dec 1, 2020 at 10:23 AM G. P. B. wrote:
>
> On Tue, 1 Dec 2020 at 18:07, Paul Crovella wrote:
>>
>> On Tue, Dec 1, 2020 at 9:43 AM Christoph M. Becker wrote:
>> >
>> > On 01.12.2020 at 18:35, Aimeos | Norbert Sendetzky wrote:
>> >
>> > > Am 01.12.20 um 18:24 schrieb Christoph M. Becker:
On Tue, 1 Dec 2020 at 18:07, Paul Crovella wrote:
> On Tue, Dec 1, 2020 at 9:43 AM Christoph M. Becker
> wrote:
> >
> > On 01.12.2020 at 18:35, Aimeos | Norbert Sendetzky wrote:
> >
> > > Am 01.12.20 um 18:24 schrieb Christoph M. Becker:
> > >>
> > >>> In PHP 7, this returns FALSE:
> > >>>
> >
Am 01.12.20 um 18:56 schrieb Aimeos | Norbert Sendetzky:
Am 01.12.20 um 18:47 schrieb G. P. B.:
Or is_file could check for it, handle it gracefully, and be a safe
function to call without worrying about this undocumented edge case.
Apologize my email client sent by mistake:
But this has
On Tue, Dec 1, 2020 at 9:43 AM Christoph M. Becker wrote:
>
> On 01.12.2020 at 18:35, Aimeos | Norbert Sendetzky wrote:
>
> > Am 01.12.20 um 18:24 schrieb Christoph M. Becker:
> >>
> >>> In PHP 7, this returns FALSE:
> >>>
> >>> php -r 'var_dump(is_file("ab\0c"));'
> >>>
> >>> In PHP 8, the same
> Furthermore, Christoph's code uses str_contains() which is only
> available in PHP 8 so it's not a good workaround if PHP 7 and 8 must be
> both supported.
>
Here: https://3v4l.org/LHcmN
Am 01.12.20 um 18:47 schrieb G. P. B.:
>>> Or is_file could check for it, handle it gracefully, and be a safe
>>> function to call without worrying about this undocumented edge case.
>>
> Apologize my email client sent by mistake:
> But this has always generated a warning see:
>
On Tue, Dec 1, 2020 at 9:48 AM G. P. B. wrote:
>
>
> On Tue, 1 Dec 2020 at 17:46, G. P. B. wrote:
>>
>> On Tue, 1 Dec 2020 at 17:45, Paul Crovella wrote:
>>>
>>> On Tue, Dec 1, 2020 at 9:25 AM Christoph M. Becker
>>> wrote:
>>> >
>>> > On 01.12.2020 at 18:18, Aimeos | Norbert Sendetzky wrote:
On Tue, 1 Dec 2020 at 17:46, G. P. B. wrote:
> On Tue, 1 Dec 2020 at 17:45, Paul Crovella
> wrote:
>
>> On Tue, Dec 1, 2020 at 9:25 AM Christoph M. Becker
>> wrote:
>> >
>> > On 01.12.2020 at 18:18, Aimeos | Norbert Sendetzky wrote:
>> >
>> > > PHP 8 is stricter in checking input data then PHP
On Tue, 1 Dec 2020 at 17:45, Paul Crovella wrote:
> On Tue, Dec 1, 2020 at 9:25 AM Christoph M. Becker
> wrote:
> >
> > On 01.12.2020 at 18:18, Aimeos | Norbert Sendetzky wrote:
> >
> > > PHP 8 is stricter in checking input data then PHP 7. This is good but
> > > has some side effects for
On Tue, Dec 1, 2020 at 9:25 AM Christoph M. Becker wrote:
>
> On 01.12.2020 at 18:18, Aimeos | Norbert Sendetzky wrote:
>
> > PHP 8 is stricter in checking input data then PHP 7. This is good but
> > has some side effects for is_file(), is_dir() and similar functions when
> > invalid paths are
On 01.12.2020 at 18:35, Aimeos | Norbert Sendetzky wrote:
> Am 01.12.20 um 18:24 schrieb Christoph M. Becker:
>>
>>> In PHP 7, this returns FALSE:
>>>
>>> php -r 'var_dump(is_file("ab\0c"));'
>>>
>>> In PHP 8, the same code throws a ValueException. Problem is now that
>>> it's not possible to
Am 01.12.20 um 18:24 schrieb Christoph M. Becker:
>> In PHP 7, this returns FALSE:
>>
>> php -r 'var_dump(is_file("ab\0c"));'
>>
>> In PHP 8, the same code throws a ValueException. Problem is now that
>> it's not possible to check upfront if the passed argument is a valid
>> path to avoid the
On 01.12.2020 at 18:18, Aimeos | Norbert Sendetzky wrote:
> PHP 8 is stricter in checking input data then PHP 7. This is good but
> has some side effects for is_file(), is_dir() and similar functions when
> invalid paths are passed for checking.
>
> In PHP 7, this returns FALSE:
>
> php -r
Hi internals
PHP 8 is stricter in checking input data then PHP 7. This is good but
has some side effects for is_file(), is_dir() and similar functions when
invalid paths are passed for checking.
In PHP 7, this returns FALSE:
php -r 'var_dump(is_file("ab\0c"));'
In PHP 8, the same code throws a
On Tue, Dec 1, 2020 at 3:16 AM Bishop Bettini wrote:
> On Mon, Nov 30, 2020 at 10:56 AM Nikita Popov
> wrote:
>
>>
>> The PHP build system currently produces a "phar" command. See
>> http://manpages.ubuntu.com/manpages/xenial/en/man1/phar7.0.1.html for a
>> man
>> page.
>>
>> Apart from changes
On Tue, Dec 1, 2020 at 4:35 PM Michael Voříšek - ČVUT FEL <
voris...@fel.cvut.cz> wrote:
> Intentionally?
>
> It is an issue for static analysers...
>
> With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem,
>
> Michael Voříšek
> ČVUT FEL
Yes, this is intentional. The
Relevant: https://chat.stackoverflow.com/transcript/11?m=50929139
I also think it would be nice to have modify method in the interface
as at the moment the interface seems pretty useless. I was told this
would be BC and we are not going to change it now.
On Tue, 1 Dec 2020 at 15:35, Michael
Intentionally?
It is an issue for static analysers...
With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem,
Michael Voříšek
ČVUT FEL
Am 01.12.2020 um 15:57 schrieb Nikita Popov:
I've put up an RFC to make the handling of "null" arguments consistent
between internal and user-defined functions:
Makes sense to me, +1.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Hi internals,
I've put up an RFC to make the handling of "null" arguments consistent
between internal and user-defined functions:
https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_arg
I started an informal discussion for this change during the 7.4 cycle
already, but decided to postpone
37 matches
Mail list logo
