It looks like the limit I mentioned, used by some functions, is architecture-dependent: https://github.com/php/php-src/blob/master/Zend/zend_types.h#L288
Also, that's such a ridiculously large number for the vast majority of > people using PHP that hardly anyone ever runs into this limit. The point is not about the possibility of crossing the limit of the array, but the need for a definition is one to design a method or function whose behavior aligns with the array capabilities. This need, in fact, became more noticeable from a design point of view since the introduction of the iterable pseudo-type. No one ever said "this is what will happen if a PHP array exceeds <this> > size". Until someone does that, I cannot document it. I cannot disagree more with this statement. - Marcos 2018-08-01 16:29 GMT-03:00 Sherif Ramadan <theanomaly...@gmail.com>: > 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....@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? >> >
