Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:103015 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 38920 invoked from network); 1 Aug 2018 19:46:39 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 1 Aug 2018 19:46:39 -0000 Authentication-Results: pb1.pair.com header.from=marcospassos.com@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=marcospassos.com@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.68 as permitted sender) X-PHP-List-Original-Sender: marcospassos.com@gmail.com X-Host-Fingerprint: 209.85.218.68 mail-oi0-f68.google.com Received: from [209.85.218.68] ([209.85.218.68:37905] helo=mail-oi0-f68.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 2E/80-14835-E1E026B5 for ; Wed, 01 Aug 2018 15:46:38 -0400 Received: by mail-oi0-f68.google.com with SMTP id v8-v6so36828171oie.5 for ; Wed, 01 Aug 2018 12:46:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5TOcTmUYGnvp2jOoKT5d0Oc6kr2z0G4Dupzy7+4LfAo=; b=YMbgHR9YfZXK9h4AxPapnSki0C4jd+TKpCeVq+Kp78GV4u4sJXm2KUP7LZ4Y/XLBv6 8qoGunOMlHgJebUHiA3ekV80lkUcjeEaMVBEvgqgBgsIfCbPsWqzyGN48a5B5SSTPKfk 59L2T+FTwun6sQDPMvgbQjKbxI2x3s8UxOfipJuHIykN8EQGVcy8KnzODTqqnnBboQb3 vD9hxDHa3sfdNFABZEdsbl9IQTtYlfUMmS6tHgXWI2u7FXwdEyAGdrE+cQXWpiUKjL1Y YT4jlLkD2mXHgdIZEQJyIUACUqZUSqCjMnHZ/niz08iF84jlgjU+vauS0044lM5Qwpfe wslA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5TOcTmUYGnvp2jOoKT5d0Oc6kr2z0G4Dupzy7+4LfAo=; b=D7RRnoJ9dn2v56xCQhSw+HSy6BkIBGNf93AiqNgWcaZl6GSavzFep6udQeucXkqaN4 u+ptu7U+OsX5Ked0sghZowZhhje7gdxYRUl4wlKKAzphrbDDm6Roglnwwov4Yc7uKsPF zrleeIdFEhIDbNxdiV5Xl3UDIbWu2Bnw7hVjyP5lj4XPTMrFRgDTbqrDN4SH4/XRuo5f dS4JJ0n0OetDl/pKcmXyFaN2+JeTbcsvXVfeK9LxnGbjtJvToEvPyIof1owzTEGjHPKs Wi/JDyGjJ+24qIWq77aLDu0LQuoY5NBt1ufDxjtAZL3j0DdzWwKpAs9rRAJ1//EUEGwM YilQ== X-Gm-Message-State: AOUpUlH3luR7do0H9ReYcUaOFEGcPM4oKt7bzEpbKX2ybKZ4/csxXEHk d74biWp0RwMwkowQu/V25C0qnr9cdJdo69iUlNw= X-Google-Smtp-Source: AAOMgpfXwWbPBLNooAofEVgm3ydpcsd/Ld/mCpLEvCzjLMWVTT8qCmt32wXf3ALdGOgvystXpkiDHaVrf7jMtnmnBj8= X-Received: by 2002:aca:ab11:: with SMTP id u17-v6mr4650496oie.53.1533152795948; Wed, 01 Aug 2018 12:46:35 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a8a:10b:0:0:0:0:0 with HTTP; Wed, 1 Aug 2018 12:46:15 -0700 (PDT) In-Reply-To: References: Date: Wed, 1 Aug 2018 16:46:15 -0300 Message-ID: To: Sherif Ramadan Cc: PHP Internals Content-Type: multipart/alternative; boundary="000000000000c9fe5a057264f327" Subject: Re: [PHP-DEV] Array max size From: marcospassos.com@gmail.com (Marcos Passos) --000000000000c9fe5a057264f327 Content-Type: text/plain; charset="UTF-8" *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 : > 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 >> 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 : > >> 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 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 >> 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? >>> >> > --000000000000c9fe5a057264f327--