Angus, > > there are zillions of compile warnings about "suggest parentheses > around assignment used as truth value" in the ExtUtils::XSBuilder > generated code and a few elsewhere (when compiling with > OPTIMIZE=-Wall). I cleaned up these compile warnings with one of my > patches I posted a while ago (also included in the debian > libextutils-xsbuilder-perl package). Gerald, I can repost these > patches if they got lost somewhere. >
I just searched back in my mail folders, but I didn't found a patch for xsbuilder. So please resend it. > xs/Embperl/Req.xs gets errdat1, errdat2 and lastwarn accessors wrong. > - it thinks they're type char (not char*) and the default value for > "val" is NULL (which is wrong for a char). > > Embperl::Req::Config::mult_field_sep assigns NULL to a char type too. > - from memory, this was a simple change to ExtUtils::XSBuilder's > null_type(), to teach it about "char". > xsbuilder doesn't handle char (without *) correctly. That's known bug and needs to be fixed. > CV* foo = epxs_sv2_SVPTR() gives an "assignment from incompatible > pointer type" (at least in Embperl::Req::Config::allow()) > There is simply I typecast missing. I fixed it here in XSBuilder. > mod_embperl.c:417: warning: unsigned int format, pointer arg (arg 3) > - I'm not sure what this sprintf is trying to do; left over > debugging? You comment this line out (and the defintion of buf). It was start for some code for smarter handlin of Embperl_APPNAME, but is not working yet. > > your recent additions to Embperl/Form/Validate/ seem to have not made > it into the released tar.gz (they're in CVS). > Oops, that's. I fixed the MANIFEST > errgv_empty_set should return an I32 (not IV) to match struct ufuncs > prototype. > That's true. Is now fixed. (Stolen this from mod_perl and not verified the data type...) > epcomp.c:embperl_COmpileCmd() > - nCodeLen might need to be initialised to 0 Need not to be inialized, but I have done this now to avoid the compiler warning. > > epdom.c:DomTree_dodelete() > - xNode might need to be initialised to -1 (if ArrayGetSize(a,pLookup) == 0) > if ArrayGetSize(a,pLookup) == 0 we don't go into the while loop and nNode is never used. So no need to initialize. Thanks very much for your comments Gerald --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
