Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:74637 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 3041 invoked from network); 29 May 2014 18:01:17 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 29 May 2014 18:01:17 -0000 Authentication-Results: pb1.pair.com smtp.mail=john@bafford.com; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=john@bafford.com; sender-id=unknown Received-SPF: error (pb1.pair.com: domain bafford.com from 96.241.205.2 cause and error) X-PHP-List-Original-Sender: john@bafford.com X-Host-Fingerprint: 96.241.205.2 nova.zort.net Received: from [96.241.205.2] ([96.241.205.2:36429] helo=nova.zort.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 4F/AF-07154-BE577835 for ; Thu, 29 May 2014 14:01:17 -0400 Received: from [10.0.1.2] (pulsar.zort.net [96.241.205.6]) (authenticated bits=0) by nova.zort.net (8.14.5/8.14.5) with ESMTP id s4TI1Ag8008259 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 29 May 2014 14:01:10 -0400 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) In-Reply-To: Date: Thu, 29 May 2014 14:01:09 -0400 Cc: Nikita Popov , PHP internals Content-Transfer-Encoding: quoted-printable Message-ID: References: <2DC459EE-AE98-4CAE-977A-6FB918FDEF54@bafford.com> <537EA42B.4000000@lerdorf.com> To: Adam Harvey X-Mailer: Apple Mail (2.1878.2) Subject: Re: [PHP-DEV] Bison 3 support for PHP 5.5 From: john@bafford.com (John Bafford) On May 29, 2014, at 13:21, Adam Harvey wrote: > On 28 May 2014 08:06, Nikita Popov wrote: >> On Wed, May 28, 2014 at 1:41 PM, Derick Rethans = wrote: >>=20 >>> On Fri, 23 May 2014, Julien Pauli wrote: >>>=20 >>>> That's a no-go for 5.5. >>>> 5.5 is stable, 1year old (at this email date), and we should not >>>> change such a thing into this stable branch. >>>=20 >>> Right, but it's going to be supported for at least another year. And >>> right now, on the latest Ubuntu's with only bison 3 you can't = actually >>> build it. Because of that, a patch like this should absolutely be >>> considered. >>=20 >> The patch (as proposed) changes the ABI for zendlex and zendparse. As = such >> I don't think it's applicable to PHP 5.5 in this form. >=20 > Agreed, but as Derick said, there's definitely an argument for some > sort of Bison 3 compatibility in 5.5. >=20 > John, can you see a way =97 however hackish =97 to get Bison 3 support = in > 5.5 without changing those functions? >=20 > Thanks, >=20 > Adam If we want to fix this up for PHP 5.5, I think I see a way, and it=92ll = be super-hackish, but I think I can make it work. Basically, where = necessary, the six functions affected (zendlex, zendparse, zenderror, = ini_lex, ini_parse, and ini_error) would be given new names, and the old = names would be wrapper functions with the old ABI that call-through (and = either pass in NULL or TSRM_LS as appropriate). PHP internally would = call the new names; the only names/wrapper functions would be there for = ABI compatibility only. If that sounds reasonable, I=92ll go ahead and give that a try, and if = it works, we can merge that implementation into 5.5 and 5.6, and then I = can revert the really hacky bits in the 5.6 branch since they=92re not = necessary because we can change the ABI. Two notes: At the least, I need to update the 5.6 version of the PR to account for = that zenderror is exported as phperror, and the definition in main/php.h = is wrong. (I think; following the macros is a bit confusing.) I=92ll = take care of that later tonight. I=92d also suggest that perhaps in >=3D 5.6, those functions shouldn=92t = even be exported as part of the public API. In php-src, they=92re = basically treated as internal implementation details. zenderror and = zendlex are only ever called directly from the parser, and zendparse is = only ever called directly from the compile_(file|filename) functions in = the scanner. (That doesn=92t mean they aren=92t called from external = modules, but there=92s a lot of setup and teardown you have to do = besides, so it=92d certainly be a quite advanced use. Does anyone know = if those functions actually are used by pecl or other third-party = modules?) -John