Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:72198 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 95704 invoked from network); 4 Feb 2014 14:39:58 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 4 Feb 2014 14:39:58 -0000 Authentication-Results: pb1.pair.com header.from=anatol.php@belski.net; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=anatol.php@belski.net; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain belski.net from 85.214.73.107 cause and error) X-PHP-List-Original-Sender: anatol.php@belski.net X-Host-Fingerprint: 85.214.73.107 klapt.com Received: from [85.214.73.107] ([85.214.73.107:47225] helo=klapt.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 21/42-17725-6BBF0F25 for ; Tue, 04 Feb 2014 09:39:51 -0500 Received: by klapt.com (Postfix, from userid 33) id EF3C023D611B; Tue, 4 Feb 2014 15:39:47 +0100 (CET) Received: from 178.7.123.71 (SquirrelMail authenticated user anatol@belski.net) by webmail.klapt.com with HTTP; Tue, 4 Feb 2014 15:39:47 +0100 Message-ID: <0681aaa573a34b3e07e246e7f88efbab.squirrel@webmail.klapt.com> In-Reply-To: <52F0E8CF.7090501@hristov.com> References: <52F0E8CF.7090501@hristov.com> Date: Tue, 4 Feb 2014 15:39:47 +0100 To: "Andrey Hristov" Cc: internals@lists.php.net 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] 64 bit RFC, #2 and #3 yes From: anatol.php@belski.net ("Anatol Belski") Hi Andrey, On Tue, February 4, 2014 14:19, Andrey Hristov wrote: > On 1.02.2014 14:30, Anatol Belski wrote: > >> Hi, >> >> >> as the concerns on the BC breach by zpp and macros changes are huge, >> we've invented the below to make the essential change only visible. >> >> This branches have zpp and macros change reverted (like #2 and #3 had >> resulted yes), only the necessary 64 improvement is in place. >> >> PHP core, zpp and macros reverted to the state of mainstream >> https://github.com/weltling/php-src/tree/str_size_and_int64_old_names >> >> >> Diff of the branch with old names to master >> http://belski.net/phpz/str_size_and_int64_old_names.diff >> >> >> >> An extension ported and fully worky with 5.3/4/5 and str_size_and_int64 >> branch, diff >> https://github.com/weltling/phurple/compare/str_size_and_int64 >> >> >> The same ext how it looks now (not using the new zpp placeholders) >> https://github.com/weltling/phurple >> >> >> >> A sample extension generated with ext_skel from str_size_and_int64 >> branch with several usage examples, worky also wit h5.3/4/5 >> https://github.com/weltling/str_size_and_int64_example/blob/master/str_ >> size_and_int64.c#L47 >> >> The sample ext diff to the current mainstream base >> https://github.com/weltling/str_size_and_int64_example/compare/str_size_ >> and_int64_revert >> >> >> Were this an acceptable tradeoff for this RFC to make it, one could >> still decide it in favor of 5.6. The worries and wishes are not >> reasonless, which is clear. However I think to strike a compromise is >> important to keep balance. >> >> Regards >> >> >> Anatol >> >> >> >> >> > > I saw 2 problems with the patch, in mysqlnd. After 2 instances I stopped > reading but a parameter of type uint is being declared as php_int_t, a flag > variable. I appreciate you could take a look at this. Could you point to the exact place where you see an issue? With the replacement of uint there are multiple reasons (and we was talking about it while being on the discussion about the mysqli_poll), two main of those - php_size_t should be used for string lengths - even flags coming from userland may cause overflow in 64 bit mode So uint to php_uint_t might be because of that, depending on what you're talking about. Thanks Anatol