Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:90858
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <CA.76.03822.A4CE3A65@pb1.pair.com>
To: internals@lists.php.net
References: <56A3A01F.1020500@php.net> <05.16.03822.D5AE3A65@pb1.pair.com>
Date: Sat, 23 Jan 2016 21:10:29 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:42.0)
 Gecko/20100101 Firefox/42.0 SeaMonkey/2.39
MIME-Version: 1.0
In-Reply-To: <05.16.03822.D5AE3A65@pb1.pair.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [RFC] Generalize support of negative string offsets
From: ajf@ajf.me (Andrea Faulds)

Hi again,

Andrea Faulds wrote:
> At present a negative offset is interpreted as being the maximum string
> length plus that offset, so $str[-1] is equivalent to $str[(2**64 - 1) -
> 1]. In practice, this means you will get an empty string and an
> "Uninitialized string offset:" E_NOTICE. It's not useful except for
> extremely large strings and so I suspect that behaviour comes from an
> implementation detail (naïve signed-to-unsigned integer conversion).
>
> What you're proposing is to have the negative offset be interpreted as
> an offset from the end of the string, as the built-in functions do. This
> is more useful, but it's a change of behaviour from the present one, and
> thus a backwards-compatibility break, even if it's unlikely to affect
> real-world code. So, you might wish to mention that.

Er, ignore what I just said. Negative string offsets are actually 
special-cased and always produce an "Unitialized string offset" or 
"Invalid string offset" notice. So our current behaviour is in fact 
completely useless, not just mostly. :)

Sorry about that.
-- 
Andrea Faulds
https://ajf.me/