Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:68087 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 57370 invoked from network); 10 Jul 2013 08:21:50 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 10 Jul 2013 08:21:50 -0000 Authentication-Results: pb1.pair.com header.from=ab@php.net; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=ab@php.net; spf=unknown; sender-id=unknown Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 85.214.73.107 as permitted sender) X-PHP-List-Original-Sender: ab@php.net X-Host-Fingerprint: 85.214.73.107 klapt.com Received: from [85.214.73.107] ([85.214.73.107:53034] helo=h1123647.serverkompetenz.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 46/D0-50933-7991DD15 for ; Wed, 10 Jul 2013 04:21:49 -0400 Received: by h1123647.serverkompetenz.net (Postfix, from userid 33) id 7E3BE6BC7FB; Wed, 10 Jul 2013 10:21:39 +0200 (CEST) Received: from 94.216.60.190 (SquirrelMail authenticated user anatol@belski.net) by webmail.klapt.com with HTTP; Wed, 10 Jul 2013 10:21:39 +0200 Message-ID: In-Reply-To: References: Date: Wed, 10 Jul 2013 10:21:39 +0200 To: "Pierre Joye" Cc: "Anthony Ferrara" , "internals@lists.php.net" Reply-To: "Anatol Belski" User-Agent: SquirrelMail/1.5.2 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [PHP-DEV] String Size Refactor Progress From: ab@php.net ("Anatol Belski") Hi, On Wed, July 10, 2013 07:51, Pierre Joye wrote: >> Substr needs to be refactored to use size_t. Right now, I just raise an >> error if Z_STRSIZE > INT_MAX (or an overflow would happen). I'd love >> to see that cleaned up more. > > We should consider moving to int64_t too as well while being at it. > For many reasons or platforms it makes sense to drop (unsigned) > long/int usage as well (and all derived types) and uses (u)int*_t instead. > I'd to see this task as strongly related to the size_t move. > It will also solve many other related issues (LFS support, 64bit > integer portability issues, etc.). What do you think? > Agree 101%, while working on this I've already seen a couple of places where having int64 in zval instead of long were the right choice while porting the string stuff. Like what Anthony says about working with the string size in userspace, but the other parts of code will need it simultaneously, too. For that we've already zend_intptr_t defined in zend_types.h . Lets tweak zval definition and do it parallel. > >> Here's the branch: >> https://github.com/ircmaxell/php-src/tree/string_size_refactor_take_2 >> And the diff: >> https://github.com/ircmaxell/php-src/compare/string_size_refactor_take_2 >> >> >> If you want to help out, please let me know and let's try to coordinate >> so we don't step on each other's toes... > > It would be awesome to add this fork to lxr, it can be amazingly > helpful. From our side, we are testing and fixing (Weltling) it already, we > will try to do it on regular basis to do not stay behind or do to do not > have to debug a huge amount of changes to fix one bug or another (can be > painful with this kind of changes). > It were awesome to put this work into git.php.net space and use lxr. Best regards Anatol