Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107917
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
In-Reply-To: <CAFPFaMLfau0zRMy5eJtoF1orTxyOanT+czNNyKptZBA+=LdNRw@mail.gmail.com>
Date: Mon, 16 Dec 2019 12:20:42 +0100
Cc: PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <F5B147CF-48A9-47C6-ACCF-3A8709DD3BE8@gmail.com>
References: <CAFPFaMLfau0zRMy5eJtoF1orTxyOanT+czNNyKptZBA+=LdNRw@mail.gmail.com>
To: George Peter Banyard <girgias@php.net>
Subject: Re: [PHP-DEV] Allowing variable strings to be defined for a string
 offset
From: claude.pache@gmail.com (Claude Pache)



> Le 16 d=C3=A9c. 2019 =C3=A0 10:58, George Peter Banyard =
<girgias@php.net> a =C3=A9crit :
>=20
> Greetings internals,
>=20
> I'm here to get internals's opinion about allowing a string offset to =
be
> replaced with arbitrary strings.
>=20
> 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>
>=20
> 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).
>=20
> 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. =
This
> seems reasonable due to the possible loss of data.
>=20
> 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 =
have
> all those bytes in the string whereas before only the first one was =
used 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.
>=20
> Any opinions?
>=20
> Best regards
>=20
> George Peter Banyard
>=20
> [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 =
very 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 =
(assuming 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).

=E2=80=94Claude