Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103013
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.161.196 as permitted sender)
MIME-Version: 1.0
References: <CANA3DesUZ1T=vfvgb7T7CqMqF3KvrMzykFEAS5Y0y6Sxo0c0_A@mail.gmail.com>
In-Reply-To: <CANA3DesUZ1T=vfvgb7T7CqMqF3KvrMzykFEAS5Y0y6Sxo0c0_A@mail.gmail.com>
Date: Wed, 1 Aug 2018 15:29:57 -0400
Message-ID: <CAL+t6cH3ng_z=iGP4e5Qc1CJSFH_WfAfrKrfYTu0N1VBXOaaUw@mail.gmail.com>
To: marcospassos.com@gmail.com
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000f2549a057264b88f"
Subject: Re: [PHP-DEV] Array max size
From: theanomaly.is@gmail.com (Sherif Ramadan)

--000000000000f2549a057264b88f
Content-Type: text/plain; charset="UTF-8"

It's undocumented, because it's considered undefined behavior. PHP arrays
implicitly store the number of elements internally as an unsigned 32 bit
integer (regardless of architecture). This means that (technically) you
can't create an array with more than ((2**31) - 1) elements (or
2,147,483,647 elements). However, PHP won't actually attempt to stop you
from doing this! The problem is, once you exceed these number of elements,
the integer will overflow, causing undefined behavior (all kinds weird
bugs). So we cannot document behavior that was never defined. No one ever
said "this is what will happen if a PHP array exceeds <this> size". Until
someone does that, I cannot document it. Also, that's such a ridiculously
large number for the vast majority of people using PHP that hardly anyone
ever runs into this limit.




On Wed, Aug 1, 2018 at 2:42 PM Marcos Passos <marcospassos.com@gmail.com>
wrote:

> Whenever you look for more information about the maximum size of an array,
> you find someone saying that "PHP arrays do not have a maximum size, but
> the amount of memory available". However, I could not find any excerpt in
> PHP documentation that supports that.
>
> Even if the engine imposes no hard limit on the size of an array, in fact,
> there an inherent limit that is assumed by some functions, and that is what
> I would like to suggest making explicit on the documentation. The lack of
> this definition leads to inconsistencies and leaves several open questions,
> including:
>
>    - If no limit exists, then it's conceptually possible to have an array
>    with *PHP_INT_MAX + 1* elements. In that sense, what would be the return
>    of the *\count()*?
>    - The function *range* validates the size of the resulting range against
>    the maximum size of the hash table (defined internally as
> *HT_MAX_SIZE*),
>    and throw an error if it exceeds that value. Is that the limit?
>    - he function *array_fill*, in contrast, does not rely on *HT_MAX_SIZE*
>    for validating the size of the result. But, why?
>    - The documentation says that omitting the third parameter of
>    array_split is equivalent to \count($array). If the maximum number
>    representable in PHP is *PHP_INT_MAX*, is the max size the same as
>    *PHP_INT_MAX*?
>
> There are other examples, but I think these are enough to make the point.
>
> My understanding is that the conceptual limit is *PHP_INT_MAX*, as there is
> no way to represent the size above this value. If so, the interval that
> represents all possibles indexes for an array is defined as *0 <= index <=
> PHP_INT_MAX -1*. That definition aligns with all functions that support
> negative length as *-PHP_INT_MAX* is equivalent to the start of the array.
>
> Could you guys please share your thoughts on this topic?
>

--000000000000f2549a057264b88f--