Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91237
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 212.27.42.2 as permitted sender)
To: Stanislav Malyshev <smalyshev@gmail.com>,
 Nikita Popov <nikita.ppv@gmail.com>
References: <56A3A01F.1020500@php.net> <56BC988F.7080101@php.net>
 <D9.BC.25203.806BCB65@pb1.pair.com> <56BD1CD4.8070206@php.net>
 <CAF+90c89n8pDCh4O3J5DBTao_8+1ON0TnJTxg-GbbROPorFyGg@mail.gmail.com>
 <56C14AC6.7060307@gmail.com>
Cc: Andrea Faulds <ajf@ajf.me>, PHP internals <internals@lists.php.net>
Message-ID: <56C30C80.3080009@php.net>
Date: Tue, 16 Feb 2016 12:48:16 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <56C14AC6.7060307@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] Generalize support of negative string offsets
From: francois@php.net (=?UTF-8?Q?Fran=c3=a7ois_Laupretre?=)

Le 15/02/2016 04:49, Stanislav Malyshev a écrit :
> Hi!
>
>> This fix has been merged into master (targeting 7.1), thanks!
>
> I'm not sure that was such a good idea (sorry, didn't have time to write
> about it before the weekend). Introducing a new warning into previously
> working code is a BC break, and one that wasn't even discussed in its
> own thread. Moreover, there's one more BC break in this patch - before
> it, for this code:
>
> $str = "abc";
> $str{4} = '';
> var_dump($str);
>
> the $str was string of length 5, with this fix it would be string of
> length 3, unchanged. Which may break other code (e.g. one composing
> complex formats) in very subtle ways. And I'm not sure that current
> behavior is an improvement.

Right. Introducing a BC break in a minor version requires a consensus, 
and we should probably have discussed about it on the list, instead of 
github. So, let's discuss it further.

As we probably agree that introducing a null byte in the string is a 
bug, what fix would you suggest ?

If we consider the BC break too important for a minor version, another 
solution could be to consider an empty RHS string as a space character, 
because this is the padding char used when extending the string. There, 
we can keep almost the same behavior as the current one, except we put a 
space instead of a null byte and, maybe, raise an E_NOTICE. So, your 
example would cause $str to become "abc  " instead of "abc \0" and the 
assignement would return " " instead of "\0".

Regards

François