Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:103017 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 41967 invoked from network); 1 Aug 2018 19:56:10 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 1 Aug 2018 19:56:10 -0000 Authentication-Results: pb1.pair.com smtp.mail=marcospassos.com@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=marcospassos.com@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.67 as permitted sender) X-PHP-List-Original-Sender: marcospassos.com@gmail.com X-Host-Fingerprint: 209.85.218.67 mail-oi0-f67.google.com Received: from [209.85.218.67] ([209.85.218.67:43210] helo=mail-oi0-f67.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 7E/21-14835-950126B5 for ; Wed, 01 Aug 2018 15:56:09 -0400 Received: by mail-oi0-f67.google.com with SMTP id b15-v6so36868170oib.10 for ; Wed, 01 Aug 2018 12:56:08 -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=2SgAgpv0xIG4F+GszQ1OBOh86C5Zkiw0RHB+sxoMuZI=; b=qLWEh84p5nzI0sIAGwijAMIzwHyPQrBIVKwR6KkLI5UbUtKLDEqXz2bgEZOsLOEhCn zxtfjeETOzmI06jj4NZxSBAhdf3YyKx30G3oFkr+m9hELkH1yoqOaKtpmirK1q0sK859 b1qFJ+gGIdxKunJyJA/d+gbqLTUVoHCmwbLSE2gtRLKHr84T/GbrLmjWdrOccxQuMVLS 8Be3p0L9x3fY+E0rF8z63/wBYo7Th3prSzFfNuT91UWjKYA2Mo+uIZkdTSVI2IKKRryU z2FSJDTaalCqsTf5TahMiqhtIWbRBmHV/QtVB5HkBFKbbwNXfe2RUgi1gjltaPa3rz9m YAEw== 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=2SgAgpv0xIG4F+GszQ1OBOh86C5Zkiw0RHB+sxoMuZI=; b=dmcuOQ0XgJ5zsLEct2/rKrGEflu7/UJ32E6jMFWtjUXcUqh3U1kDixmC8WiiB0zwl8 jFOJJWMmCd2NPrv++KQKfcA6IHmWdnhogqlWNXJWjsCRvHSNGsZGCTrXgeMz1Wz33+35 YcoZZlkq/5fsp7ggpAUMfxgzX+uHOTrV/4EQfESGaVyivSLEFO+/f5GH2YdzUfFGzs8c vT/zqBqE2x50t6ZNS9IL1o5GIuFpot/clTwEFSfPMiMcsrHxFoFGLUXd4mTln1RRkDaz qyVjX0ay5bAJJ65sRyv7Q87qKnHZHnDc7ue8A+CNI65bAhV4spDc98pOcXKM6jn/dS00 D4Pg== X-Gm-Message-State: AOUpUlHYwPfm7lVSfolLfALS7DLWOT1aBkFha+R1NJST6kFPv/DWb/IA 61DkaVaqW+gD03IVblHuhKL5mK458dnp2TQCMuk= X-Google-Smtp-Source: AAOMgpc781CAfOzQY8J/iHKowT8a0Oy9+uZ+xM55CpPc7mYvULYGCiwpwjLpThtqxNNGFSqfGZAnBShU7YVGneKNNas= X-Received: by 2002:aca:f409:: with SMTP id s9-v6mr5312847oih.102.1533153366003; Wed, 01 Aug 2018 12:56:06 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a8a:10b:0:0:0:0:0 with HTTP; Wed, 1 Aug 2018 12:55:45 -0700 (PDT) In-Reply-To: References: Date: Wed, 1 Aug 2018 16:55:45 -0300 Message-ID: To: Sherif Ramadan Cc: PHP Internals Content-Type: multipart/alternative; boundary="000000000000c458c2057265151b" Subject: Re: [PHP-DEV] Array max size From: marcospassos.com@gmail.com (Marcos Passos) --000000000000c458c2057265151b Content-Type: text/plain; charset="UTF-8" If you are arguing strictly about not knowing what to write on the documentation, let's move the discussion towards whether it should be defined or not. 2018-08-01 16:51 GMT-03:00 Sherif Ramadan : > Right, and therein lies the problem. No one has ever defined this > behavior. As such, one cannot document what has never been defined. > > What you're describing is UNdefined. Undefined things cannot be documented. > > > On Wed, Aug 1, 2018, 3:46 PM Marcos Passos > wrote: > >> *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 < >>>> 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? >>>>> >>>> >>> >> --000000000000c458c2057265151b--