On Wed, Jun 17, 2015 at 12:20 AM, Christoph Becker <cmbecke...@gmx.de>
wrote:

> Johannes Schlüter wrote:
>
> > On Tue, 2015-06-16 at 02:02 +0200, Christoph Becker wrote:
> >> Johannes Schlüter wrote:
> >>
> >>> It is not including the generated parsers. This means the user might
> use
> >>> a different version, which might cause a bug which might be hard to
> >>> debug as usage of provided files is assumed.
> >>
> >> Fair enough.  However, the Windows sources neither contain the generated
> >> parser files, because they would break linking on Windows, see
> >> <http://news.php.net/php.internals/86685>.
> >
> > This is a bug and has to be addressed.
>
> I have investigated further.  The issue is commit b8e2629[1].  I'm
> certain that Sara had good reasons to mark zendparse() as ZEND_API.
> However, that breaks building with the generated zend_language_parser
> files with MSVC, if they have been generated with a somewhat recent
> bison (2.4.1 still works, 2.7.12 fails), because newer versions declare
> zendparse() again in .c and .h – without ZEND_API.
>
> It seems the only possibility to fix this mismatch would be to use a
> custom skeleton, but the /usr/share/bison/README states:
>
> | These skeletons are the only ones supported by the Bison team.
> | Because the interface between skeletons and the bison program is not
> | finished, *we are not bound to it*.  In particular, Bison is not
> | mature enough for us to consider that "foreign skeletons" are
> | supported.
>
> So what to do?
>
> [1]
> <
> https://github.com/php/php-src/commit/b8e262901e56a4d9a6664d348c9878246579239e
> >
>

We need some ZEND_API way to invoke the parser from extensions. If it's
inconvenient to have on zendparse() directly because bison, I'd suggest
dropping it there and creating a ZEND_API wrapping function.

Nikita

Reply via email to