Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110775
MIME-Version: 1.0
References: <CAFPFaMK2ku+Jicv2znPnOb7RUQRc8iyVxRNOzjxRRmZh04RB2A@mail.gmail.com>
 <A3CDC880-BF7D-47EB-A3D3-63037C543E15@gmail.com>
In-Reply-To: <A3CDC880-BF7D-47EB-A3D3-63037C543E15@gmail.com>
Date: Mon, 29 Jun 2020 15:01:00 +0200
Message-ID: <CAFPFaM+yLUFj5+HFn7RQw47nYFGFbqY1XQfqYsyb-1Pt=7JUjg@mail.gmail.com>
To: Claude Pache <claude.pache@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000008feb105a938a78a"
Subject: Re: [PHP-DEV][RFC] Saner numeric strings
From: george.banyard@gmail.com ("G. P. B.")

--00000000000008feb105a938a78a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 29 Jun 2020 at 14:53, Claude Pache <claude.pache@gmail.com> wrote:

>
> > Le 29 juin 2020 =C3=A0 12:30, G. P. B. <george.banyard@gmail.com> a =C3=
=A9crit :
> >
> > Greetings internal,
> >
> > While reviving the "Permit trailing whitespace in numeric strings" RFC
> [1]
> > I didn't see Nikita's comment on Andrea's original PR which commented o=
n
> > the fact that we should get rid of the "leading-numeric string" concept=
.
> >
> > Therefore, mostly due to time constraints, I've merge the trailing
> > whitespace RFC with the removal of this concept in the following RFC:
> > https://wiki.php.net/rfc/saner-numeric-strings
> >
> > The main gist is to convert all E_NOTICEs  =E2=80=9CA non well formed n=
umeric
> value
> > encountered=E2=80=9D to the usual E_WARNING =E2=80=9CA non-numeric valu=
e encountered=E2=80=9D and
> > allow trailing whitespaces, which would be most reasonables cases where
> the
> > E_NOTICE has been emitted.
> >
> > This RFC is heavily based on Andrea's original RFC [1] and I would like
> to
> > thank her once more for the preliminary work she's done that I could
> reuse.
> >
> > Best regards
> >
> > George P. Banyard
> >
> > [1] https://wiki.php.net/rfc/trailing_whitespace_numerics
>
>
> Hi,
>
> It is not clear for me, by reading the RFC, whether or not the behaviour
> of either implicit or explicit conversion of so-called leading numeric
> string will be preserved, beyond some Notices that will be converted to
> Warnings in the implicit case. For example, does (int) "2px" still produc=
e
> 2, even when the string is now considered as non-numeric?
>
> I think it is important to make sure that the current results of casting
> to int/float will not change. For example, I can imagine some script that
> reads a CSS value like "2px" and does some calculation on it, converting =
it
> to a number on the process. A Warning instead of a Notice will prompt the
> programmer to add explicit casts, which is probably a good thing. But
> changing the casted value to 0 would lead to bugs that are (1) harder to
> detect especially if the program already uses explicit casts, and (2)
> harder to correct.
>
> =E2=80=94Claude
>

The behaviour of explicit casts (or any other conversion which accepts
errors in the string,
which corresponds to the 1 mode of allow_errors in the relevant C
is_numeric_string function)
will be preserved, so this should still produce 2.

I will add test cases and clarify this in the RFC.

Best regards

George P. Banyard

--00000000000008feb105a938a78a--