Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88477
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain siobud.com designates 104.236.58.159 as permitted sender)
Date: Thu, 24 Sep 2015 10:02:35 -0500
To: Derick Rethans <derick@php.net>
Cc: internals@lists.php.net
Message-ID: <20150924150235.GA78250@3006.local>
References: <20150923203939.GA40539@3006.local>
 <alpine.DEB.2.20.1509241057050.21225@whisky.home.derickrethans.nl>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.20.1509241057050.21225@whisky.home.derickrethans.nl>
User-Agent: Mutt/1.5.23 (2014-03-12)
Subject: Re: [PHP-DEV] zend_parse_parameters changes not fully documented in
 phpng-upgrading, PR to fix existing tools
From: sean@siobud.com (Sean DuBois)

On Thu, Sep 24, 2015 at 11:01:09AM +0100, Derick Rethans wrote:
> On Wed, 23 Sep 2015, Sean DuBois wrote:
>
> > Hey list,
> >
> > 'l' had a change 'long' -> 'zend_long' and 's' had a change 'int' ->
> > 'size_t'.
> >
> > These two changes are really hard to catch when porting an extension,
> > nothing complains at compile time, you don't get segfaults when
> > calling zend_parse* but usually later and it is platform dependent
> > (Windows for me when porting phpredis) I am lucky that I had a
> > developer (Jan-E) help me with this, or I would have pushed the
> > extension out the door broken for many people.
> >
> > A.) Can someone merge https://github.com/php/php-src/pull/1521 this is
> > currently the only solution I know of to catch these things in an
> > automated way
>
> I didn't know this script existed! I've added a few comments. Once
> resolved, I'll merge it.
>
> > B.) Can someone give me access to https://wiki.php.net/phpng-upgrading
> > so I can document this
>
> What's your wiki username?
>
> > C.) Has there ever been a conversation about improving extension
> > building so that authors don't have to go out of their way to catch
> > these things? I would really like to see phpize kick out a Makefile
> > that in the process of building/testing would raise alerts about this.
>
> Conversations yes, solutions, no. I'd be awesome to have this though.
>
> cheers,
> Derick
>
> --
> http://derickrethans.nl | http://xdebug.org
> Like Xdebug? Consider a donation: http://xdebug.org/donate.php
> twitter: @derickr and @xdebug
> Posted with an email client that doesn't mangle email: alpine

Thanks for the review Derick! I addressed the issues you mentioned, and
hopefully it should be good to go!

My wiki username is Sean-Der

What do you think would be the most effective way to get everyones
suggestions? Continue this thread, RFC or start a new email
thread?

I would just like to see things like this script made more visible to
developers, that warn at compile time if users are using a non-public
component. Right now is there a way to know if something is going to
change, or if it safe to use?