Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:64829 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 37670 invoked from network); 10 Jan 2013 21:59:23 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 10 Jan 2013 21:59:23 -0000 Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.153 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 67.192.241.153 smtp153.dfw.emailsrvr.com Linux 2.6 Received: from [67.192.241.153] ([67.192.241.153:34942] helo=smtp153.dfw.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 61/8F-02684-AB93FE05 for ; Thu, 10 Jan 2013 16:59:23 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp15.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 1E9FE3004FA; Thu, 10 Jan 2013 16:59:20 -0500 (EST) X-Virus-Scanned: OK Received: by smtp15.relay.dfw1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id F2A5D3000A9; Thu, 10 Jan 2013 16:59:18 -0500 (EST) Message-ID: <50EF39B6.1080703@sugarcrm.com> Date: Thu, 10 Jan 2013 13:59:18 -0800 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Gustavo Lopes CC: internals PHP References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Add a zend_qsort_r/zend_qsort implementation From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > We could export zend_qsort_r starting in 5.5; I need it ext/standard so > it need not be exported, which would be problematic on a stable branch. > It's undefined behavior because the comparison function is being called > with one extra pointer argument. This is the same technique glibc uses > though, so it should be safe. I could not find any measurable > performance penalty. I think this is OK for 5.5, but I'm kind of worried about the function parameter mismatch. PHP is run on all kinds of platforms, including those where glibc is never heard of :) Are we sure it's safe on all platforms to do this? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227