Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:101730
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.48 as permitted sender)
MIME-Version: 1.0
Sender: are.you.winning@gmail.com
In-Reply-To: <CAGAGxbZ3RrkaSrAnXN2tEH4SF9YXzFKrGYiU2s5Lc+4Umt--bA@mail.gmail.com>
References: <CAGAGxbZ3RrkaSrAnXN2tEH4SF9YXzFKrGYiU2s5Lc+4Umt--bA@mail.gmail.com>
Date: Tue, 30 Jan 2018 11:56:27 +0000
Message-ID: <CAGAGxbYiKHOhPxiWaJP-UAXLLc9cdJBx-jvpFqaD8FuEq4QPFg@mail.gmail.com>
To: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="f403045c29fe7d8ce10563fd0da8"
Subject: Re: unpack() offset and consumed data measurement
From: cw@daverandom.com (Chris Wright)

--f403045c29fe7d8ce10563fd0da8
Content-Type: text/plain; charset="UTF-8"

On 28 January 2018 at 12:12, Chris Wright <cw@daverandom.com> wrote:
>
> Here is some code that demonstrates the problem:
>
>     /* This is the only way to know for certain how big float is on the
> local system */
>     define('FLOAT_WIDTH', strlen(pack('f', 0.0)));
>
>     /* an exaggerated example using two variable width codes and a code
> that
>        does not produce output but modifies the input buffer offset */
>     $pieces = unpack('f/X/Z*', $data, $offset);
>
>     /* we now have to modify the offset before we can continue to unpack
> data */
>     $offset += FLOAT_WIDTH         // f
>              - 1                   // x
>              + strlen($pieces[3]); // Z*
>

Re-reading this mail I have noticed there was a small mistake in the code
sample, in that I forgot to include the terminating null byte for the Z*
data.

This (unintentionally) demonstrates the exact reason I would like to add
this, as it's very easy to accidentally write subtle bugs.

--f403045c29fe7d8ce10563fd0da8--