the issue here isn't related to the new hook, but rather my use of setting the return status based on $r->args - I think $port was getting assigned the PV value and mod_perl isn't getting the associated IV. int() was just my workaround.
confirmed via Devel::Peek.
but yes, it's somewhat of a real issue (though apparently not, if nobody has reported it yet).
I'll do some investigation and see it I can't fix it for everyone.
attached is a first pass at fixing the problem, coupled with the removal of rc guessing that was already +1'd.
the fix involved checking for both SvIOK and SvPOK. in the case of SvIOK we call SvIVX directly (no need for SvIVx, since we're already IOK) and return the int. if SvPOK we call SvIVx to coerce the string to an integer and return that.
is it possible that that later on we will have callbacks that return a string, which is a valid thing? Aren't we guessing here again? That's why I had the idea of doing a specific handling of return code, by the callback type where we know exactly what to expect. so if it's a default_port callback we know that we need to force pv->iv, but we don't need to run this code for all other handlers. If we prepare an array of supported callbacks with integer entries, a simple switch with a logic specific to each callback will be a much cleaner solution, IMHO.
of course, neither of these protects against 'return "foo"', but I didn't see an easy way to trap that and I don't see that as a big issue, as strings were getting translated to OK already.
however, I'm especially interested if SvIV coerces all strings into 0 on all platforms, as I specifically test for that. if not, we can just remove that test.
0 only if the string starts with non-digit, but otherwise it can be a number as well, perl -le 'print int "9bar"' prints 9.
as for the rest, the return status of the callback is passed directly back to apache. the only exception are handlers with no return status, such as ModPerl::Util::exit, which gets translated as OK.
so we used to have all callbacks returning status (besides the exit() hack, which could probably be workarounded to return a special status as well), but now we get callbacks returning potentially anything.
for the most part, I like the behavior. the only thing that bothers me is whether or not to treat 1 as special, but then we get into the guessing game again, and I'd rather enforce good API use (all handlers ought to return a valid status) over trickery. so we throw a meaningful error message there and leave it to the user to fix.
+ /* XXX special error logging for possible Perl gotcha */ + if (status == 1) { + ap_log_error(APLOG_MARK, APLOG_ERR, 0, s, + "Perl callback returned 1 - did you forget to return Apache::OK?\n"); + }
why 1? it can be any value from the last evaluation if there is no explicit return.
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
