On 04/12/2020 00:57, Stanislav Malyshev wrote:
You may assert anything, but it's a fact that PHP functions have
returned nulls on bad values since forever.
I'm not disputing that. I'm disputing that anyone looking at the name or
documentation of this particular function would guess that "fo
Hi!
While it's clear that passing e.g. an array falls into the scope of that
general note, it doesn't say anywhere on that page that a string value
which contains "\0" is "not what it expects", and I don't think I would
ever have guessed that before reading this thread.
So I stand by my asse
On 03/12/2020 06:52, Stanislav Malyshev wrote:
PHP functions always returned null on bad parameters, so it's not
exactly unexpected.
and
On 02/12/2020 23:49, Christoph M. Becker wrote:
Just to reiterate, the former behavior was documented[1], and the return
value was*undefined*. Instead of
Le Tue, 1 Dec 2020 12:06:22 -0800,
Stanislav Malyshev a écrit :
> 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
> does exactly what I need, so it's correct.
Hear hear. I think this is the best s
Hi!
Just to reiterate, the previous implementation was also bad - it
returned an entirely undocumented and unexpected null value.
PHP functions always returned null on bad parameters, so it's not
exactly unexpected.
--
Stas Malyshev
smalys...@gmail.com
--
PHP Internals - PHP Runtime Developm
On 03.12.2020 at 00:06, Rowan Tommins wrote:
> On 2 December 2020 22:38:13 GMT+00:00, "Björn Larsson"
> wrote:
>
>> One could add that here the PHP programmer need to do work that
>> basically
>> replicate how the code worked earlier for little gain.
>
> Just to reiterate, the previous implement
On 2 December 2020 22:38:13 GMT+00:00, "Björn Larsson"
wrote:
>One could add that here the PHP programmer need to do work that
>basically
>replicate how the code worked earlier for little gain.
Just to reiterate, the previous implementation was also bad - it returned an
entirely undocumented a
Den 2020-12-01 kl. 20:57, skrev Stanislav Malyshev:
Hi!
Is a warning fine because null bytes indicate a potential attack as
in no
sane context should null bytes be passed around?
A warning is fine because it does what it's supposed to do - fails the
is_file check (which is literally only t
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 d
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 a
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 to
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 a
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.
Wo
On Tue, Dec 1, 2020 at 7:58 PM Christoph M. Becker
wrote:
> 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
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 b
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 Sendetzky
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
> originally
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 al
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 c
> 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
(https://link.getmailspring.com/link/cf1dfc14-e01b-46b3-9719-6dca72108...@getmailspring.com/0?redirect=http
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:
> https://3v4l.org/7E
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 is_fil
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 pas
29 matches
Mail list logo
