Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74247
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain phpdoc.de from 85.13.130.122 cause and error)
Message-ID: <5375A15A.5020104@phpdoc.de>
Date: Fri, 16 May 2014 07:25:46 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <CAEZPtU6OfLM7M31TeoO587aeVgskEy9ZrUaMv-t7sq0g2spSdw@mail.gmail.com>	<537539AC.8080906@sugarcrm.com> <CAEZPtU6sTGh_XWJedQs4KCuzUxDsuhnLwkgLJj3tGdPvRG3Tng@mail.gmail.com>
In-Reply-To: <CAEZPtU6sTGh_XWJedQs4KCuzUxDsuhnLwkgLJj3tGdPvRG3Tng@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] on memory usage with the 64bit patch, and interpretation
 of various numbers
From: ulf.wendel@phpdoc.de (Ulf Wendel)

Am 16.05.2014 05:31, schrieb Pierre Joye:
> Hi Stas,
> 
> On Fri, May 16, 2014 at 12:03 AM, Stas Malyshev <smalyshev@sugarcrm.com> wrote:
>> Hi!
>>
>>> ### It's The Correct Data Type
>>>
>>> The C89 spec indicates in 3.3.3.4 (
>>> http://port70.net/~nsz/c/c89/rationale/c3.html#size-95t-3-3-3-4 ) that
>>> the size_t type was created specifically for usage in this context. It
>>> is always, 100% guaranteed to be able to hold the bounds of every
>>> possible array element. Strings in C are simply char arrays.
>>
>> Here is my problem with it - we don't need a type that allows to hold
>> the bounds of every possible array element. It's like buying a house
>> that could contain all your relatives, acquaintances, friends and people
>> that you have ever met if they would decide to come to you to stay all
>> at once.
>> Too expensive and very impractical. We're using unified string
>> sizes now, and 99% of the strings we're using never even reach limits of
>> 16 bits, let alone come close to limits of int. Carrying around a 64-bit
>> value to store that is just waste. We'd be just storing megabytes of
>> zeroes without any use. Whatever theoretical reasons there are for
>> generic application to use that, they hardly can be applied to very
>> specialized and supposed to be highly optimized case as the language
>> engine is. It's a fine argument in the generic case, but we do not have
>> the generic case here.
> 
> 
> I wonder if one actually reads it correctly and other replies, but let
> me say it again.
> 
> It is a side effect not a goal, at all.

Assuming unified behaviour is the #1 goal, the lowest common denominator
could be used instead of the largest. The latter  obviously has
undesired side effects.

Ulf