2009/4/1 Johannes Schlüter <johan...@schlueters.de>: > Hi, > > On Wed, 2009-04-01 at 16:16 +0100, Paul Biggar wrote: >> I think that to handle more complex cases we need the kind of >> information which makes it straightforward to easily generate code to >> make a seamless interface between C and the engine API. The only case >> I had thought of was to somehow mangle structs/pointers into >> resources. But I suppose we need lengths for strings. I expect (many?) >> more of these cases will come up. > > Well, as soon as any pointer exists you need manual work for a special > case. And even when only using integers it's not fully fast-forward: > There are cases where not the full integer range is allowed but just a > few flags or some specific range. C programmers will know that, passing > that 1:1 to PHP userland can be bad.
Well, it depends what the pointer does of course. I dont know if we need to support the general case of 'anything goes with pointers'. Instead, I had been thinking that the pointer would be a pointer to a struct, in the manner of 'OO-in-C'. > For simple cases http://pecl.php.net/package/ffi might be enough, for > average cases there are just a few APIs (PHP_FUNCTION, > zend_parse_parameters, RETURN_*) one has to know for a start for an > extensions, Hartmut's CodeGen_PECL abstracts that using some XML and > then there's PEAR's Inline_C as some "weird" approach. I'll take a look at these, thanks for the pointers. However, the main idea is not exactly what we use, just that we no longer use the Zend API. > I'd be happy to have some simple toolkit for this, but I guess it's > really hard to make some easy tool which really works in average cases > not just in proof-of-concept cases. This might also be interesting for > other projects like ProjectZero (PHP using a JVM) or pipp (using Parrot) Yes. This is one of the motivations. In theory, Project Zero (et al) would generate their own code from the library spec. AFAIK, they currently go through the Zend API, which I believe there not too happy about. Thanks, Paul -- Paul Biggar paul.big...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
