perl-embperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gerald Richter" <>
Subject Re: ANNOUNCE: Embperl 2.0b9
Date Thu, 12 Jun 2003 20:31:13 GMT

> 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

> 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


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message