Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69310
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.169 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <51ADEAA7.9080309@hoa-project.net>
References: <CAAyV7nG126YkpOF-EShHbf=4rgX7gQ2VE0ShRh0-50_Yr--h4g@mail.gmail.com>
	<3e1b2d12-97cd-4928-b526-0a4b9d443ca5@email.android.com>
	<51ADA82F.6040407@hoa-project.net>
	<CAEZPtU6_oBUL_5nzV5+KSJ9R+mpUBDwVXiRk1i2AkNrFGBGV_g@mail.gmail.com>
	<51ADEAA7.9080309@hoa-project.net>
Date: Tue, 24 Sep 2013 10:00:11 +0200
Message-ID: <CAEp07h91YCdravVeV6jTXNSdexnrV1swp8oWW5mRi9BYGoPyxA@mail.gmail.com>
To: ivan.enderlin@hoa-project.net
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e013cbdc4a89c5c04e71c86bd
Subject: Re: [PHP-DEV] 5.NEXT Integer and String type modifications
From: martin.keckeis1@gmail.com (Martin Keckeis)

--089e013cbdc4a89c5c04e71c86bd
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2013/6/4 Ivan Enderlin @ Hoa <ivan.enderlin@hoa-project.net>

>
> On 04/06/13 12:08, Pierre Joye wrote:
>
>> On Tue, Jun 4, 2013 at 10:41 AM, Ivan Enderlin @ Hoa
>> <ivan.enderlin@hoa-project.net**> wrote:
>>
>>> Hey :-),
>>>
>>>
>>> On 02/06/13 08:52, Johannes Schl=C3=BCter wrote:
>>>
>>>> It would be a *gigantic* patch, but the userland effects should be
>>>>> minimal (the only changes would be supporting longer strings, and
>>>>> consistent 64
>>>>> bit int support). The performance considerations should be minimal fo=
r
>>>>> non-legacy code (as both would still be using native data types)...
>>>>>
>>>> History shows that such gigantic patches are often not finished and do=
ne
>>>> as people underestimate the size of PHP and the fact that all etension=
s
>>>> have
>>>> to be checked which for this case means checking each external lib for
>>>> their
>>>> correct type for all their functions etc ... but I don't wan to stop
>>>> you,
>>>> I'm happy if you do this :-) (while I'm also happy about everybody
>>>> spending
>>>> time on fixing bugs instead of adding such high-risk changes  ;-))
>>>>
>>> Is it possible to use a static C analyzer here? It could help a lot. I
>>> think
>>> about Frama-C [1], Pork [2] (now included in Oink [3]) or Clang Static
>>> Analyser [4] to name a few. A more complete list can be found in [5].
>>>
>> We do it using Visual C++ static analyzer, which is an excellent tool
>> for this kind of issue, almost on all commits. As soon as we have a
>> fork for these changes I will add it so we can get regular updates.
>>
> Excellent!


Since Anthony is sadly gone, is there still something going on in this
direction?
Just fallen into a bug related to this with future DateTimes.... after
2038-01-19
03:14:07

--089e013cbdc4a89c5c04e71c86bd--