*The point is not about the possibility of crossing the limit of the array, but the need for a definition so one can 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.
2018-08-01 16:44 GMT-03:00 Marcos Passos <marcospassos....@gmail.com>: > 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? >>> >> >
