From: Kevin R. <kr...@su...> - 2006-11-10 21:11:22
|
Olly Betts wrote: > On Fri, Nov 10, 2006 at 12:02:15PM -0600, Kevin Ruland wrote: > >> Olly Betts wrote: >> >>> With SWIG from branch-php-utl and PHP4, the generated wrapper for Xapian >>> doesn't even build. >>> >> Thanks for checking. That's why it was a branch :) >> > > Yeah, I didn't mean that to sound critical. > > I didn't take your comment as a criticism. I'm glad you're trying it. >> To be perfectly honest, I don't know if there is much benefit trying to >> do anything other than zend_error for the exceptions & error handling. >> > > For PHP5, we have the option of throwing PHP exceptions. > > >> The reason I didn't do zend_error, was it appeared to me that that >> method did some kind of long jump and didn't allow swig wrapper code to >> clean up (such as delete temporaries, etc). It was that reason why I >> introduced the message and code macros & thread local variables. >> Perhaps we should make these variables on the stack and try to do >> something much easier. >> > > Perhaps we should be using an "auto_ptr"-like pattern which will > delete the contain pointer before the wrapper returns. Hmm, though that > probably doesn't help if we exit the function with longjmp(). > > I don't recall exactly how much I dug into the PHP 4 source when I first updated the swig code. My first pass at error handling code did exactly call zend_error then SWIG_fail; which does the goto. I noticed that it never did the goto and I ended up leaking memory if zend_error was executed. Maybe we can use macros and conditional compiles so the same code generator (php.cxx) can be used but the runtime slightly different when building against different versions of PHP. Or, if anybody knows the proper way to handle errors in php4 that would be fine too. I did glance at some of the ext code provided in the php4 source bundle and they use zend_error and probably don't worry about side effects. Since php is typically used for short running programs (single web pages..) then some leaking probably is acceptable. >>> Next problem - I have a few custom typemaps which call SWIG_ConvertPtr. >>> However, the prototype for this has changed and it now wants "zval **" for >>> the first argument (this used to be "zval *"). I can't see why that's >>> changed though - it doesn't look like SWIG_ConvertPtr now modifies >>> this argument or anything like that... >>> >> Right. This is to work around an assumption Marcello made when he did >> the UTL. Basically, UTL assumes that the same type is used for both >> input and return types. Since PHP return values are passed as >> parameters with type zval ** and other parameters are passed as zval *, >> > > Aha, this makes a bit more sense then. Annoying that it breaks any > custom typemaps which call SWIG_ConvertPtr though. We could perhaps > provide an overloaded version for C++ wrappers at least, but perhaps > it's better to break compatibility for C++ if we do for C. > > Maybe I misinterpreted Marcello's intentions. The type zval ** is %defined some place in the UTL setup code. Maybe looking at how this is used in the Magic Macros would indicate I didn't understand what was going on. >> I basically had to make some ugly hacks to get it all to work out. If >> you look carefully, there are some ugly casts which allow all this to >> work. Of course, I documented this code very well didn't I. >> > > I haven't actually looked at the changes to swig itself, only the > generated code. > > These are all in the runtime & typemap code. I think I only made a small handful of changes in the php.cxx file itself. >>> Anyway, hacking my typemaps to reflect this change, the next problem I hit >>> is there's lots of errors for lines of generated code like this: >>> >>> if (SWIG_IsNewObj(res2)) delete arg2; >>> >> I don't know where these are generated. >> > > I'll try to take another look. I'm interested to see if the UTL based > code works at runtime. > The examples run :) but that's not a very good test. > Cheers, > Olly > > > > Kevin |