Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107929
MIME-Version: 1.0
References: <CAFPFaMLfau0zRMy5eJtoF1orTxyOanT+czNNyKptZBA+=LdNRw@mail.gmail.com>
 <F5B147CF-48A9-47C6-ACCF-3A8709DD3BE8@gmail.com>
In-Reply-To: <F5B147CF-48A9-47C6-ACCF-3A8709DD3BE8@gmail.com>
Date: Thu, 19 Dec 2019 14:18:00 +0100
Message-ID: <CAF+90c87CXiEauGMLBi92ExdVmUGmf+ZV7myWvXCwJdPf9wAGg@mail.gmail.com>
To: Claude Pache <claude.pache@gmail.com>
Cc: George Peter Banyard <girgias@php.net>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000e5b62b059a0e648a"
Subject: Re: [PHP-DEV] Allowing variable strings to be defined for a string offset
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000e5b62b059a0e648a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Dec 16, 2019 at 12:21 PM Claude Pache <claude.pache@gmail.com>
wrote:

>
>
> > Le 16 d=C3=A9c. 2019 =C3=A0 10:58, George Peter Banyard <girgias@php.ne=
t> a =C3=A9crit
> :
> >
> > Greetings internals,
> >
> > I'm here to get internals's opinion about allowing a string offset to b=
e
> > replaced with arbitrary strings.
> >
> > Since forever strings with more then one byte have been truncated
> silently
> > to one byte. The case with empty string *kinda* was existent but had a
> > buggy behaviour (see bug 71572 [1]) and as such has been turned into a
> > warning in PHP 7.1.0, and is meant to be promoted to an Error Exception
> per
> > the Reclassifying engine warnings RFC. [2]
> > An illustration of both these cases is available on 3v4l.org [3]
> > <https://3v4l.org/O0nEM>
> >
> > I've got an implementation ready as a pull request on GitHub [4] (which
> > still needs some polishing for it to make CI happy and fix the various
> > leaks).
> >
> > However, the question is if this behaviour is desirable. Moreover, the
> > silent truncation of strings with more than one byte should be changed =
to
> > the same severity as the empty string case; i.e. an Error Exception. Th=
is
> > seems reasonable due to the possible loss of data.
> >
> > What ever the decision is, a BC break is to be expected. As code which
> > inadvertently tries to assign multiple bytes to an offset will know hav=
e
> > all those bytes in the string whereas before only the first one was use=
d
> to
> > replace the byte at the designated offset. On the other hand the
> > introduction of an Error Exception is obviously a BC break but as it
> points
> > out to some kind of logic error.
> > I would assume the impact to be minimal for both of these case.
> >
> > Any opinions?
> >
> > Best regards
> >
> > George Peter Banyard
> >
> > [1] https://bugs.php.net/bug.php?id=3D71572
> > [2] https://wiki.php.net/rfc/engine_warnings
> > [3] https://3v4l.org/O0nEM
> > [4] https://github.com/php/php-src/pull/5013
>
>
> Being able to replace one byte with an arbitrary string does not seem ver=
y
> useful to me, unless you add the functionality of replacing an arbitrary
> substring with an arbitrary string (an equivalent of array_splice() for
> strings). Your implementation gives the following potentially surprising
> result:
>
> <?php
> $str =3D "Hello world";
> var_dump(strlen($str)); // 11
> $str[0] =3D "=E3=81=82"; // replace the first byte with three bytes (assu=
ming source
> code is UTF-8-encoded)
> $str[0] =3D "H"; // replace the first byte with one byte
> var_dump(strlen($str)); // 13
> ?>
>
> IMO, the only reasonable thing to do at this point is just emitting a
> Warning (or an Error).
>

I agree. As it's currently silently accepted, I'd recommend starting with a
warning.

Nikita

--000000000000e5b62b059a0e648a--