Geoffrey Young wrote:
should be just a matter of setting PerlSwitches -w in the test suite
(though who knows what that will start doing :)
Yup, it reveals a few more issues with undef. I'm looking at it.
I'll commit that change a bit later.
ok, I'll leave it to you, then.
I meant the -w chan
should be just a matter of setting PerlSwitches -w in the test suite
(though who knows what that will start doing :)
Yup, it reveals a few more issues with undef. I'm looking at it.
I'll commit that change a bit later.
ok, I'll leave it to you, then.
the only thing I would suggest is to rever
Geoffrey Young wrote:
What I meant is this:
if (count != 1) {
status = OK;
}
else {
SV* status_sv = POPs;
if (status_sv == &PL_sv_undef) {
/* ModPerl::Util::exit returns undef */
status = OK;
}
Geoffrey Young wrote:
have you reversed the POPs change?
of course
Here is the original report:
http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=106505218031357&w=2
yes, you did leave out the configuration information :)
oops, I was sure that what was important is 'use warnings' in the t
What I meant is this:
if (count != 1) {
status = OK;
}
else {
SV* status_sv = POPs;
if (status_sv == &PL_sv_undef) {
/* ModPerl::Util::exit returns undef */
status = OK;
}
else {
Geoffrey Young wrote:
no, I was talking about the change I did to fix the undef-on-exit
problem (i.e. replacing POPi with POPs)
ok. I didn't see how to fix the undef warning with POPi, though, since
it's undocumented what POPi returns when the stack is undef, and whether
it will always comp
have you reversed the POPs change?
of course
Here is the original report:
http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=106505218031357&w=2
yes, you did leave out the configuration information :)
it turns out the user told us exactly what the reproducability problem is -
PerlSwitches -w
Geoffrey Young wrote:
indeed. can you post the script? I'll take a look at it too and see
if I can figure out a way to reproduce it as well.
package CGItest;
sorry, I wasn't able to reproduce the warning with that script. maybe
it's something else?
have you reversed the POPs change? Here
indeed. can you post the script? I'll take a look at it too and see
if I can figure out a way to reproduce it as well.
package CGItest;
sorry, I wasn't able to reproduce the warning with that script. maybe it's
something else?
no, I was talking about the change I did to fix the undef-on-
Geoffrey Young wrote:
test suites are good for excercising functionality and some error
conditions, but not always for reproducing real-world issues like
that, unfortunately.
Frankly I don't think this applies to the undef-warn-on-exit problem,
it's reproducable in a trivial cgi script. It mu
test suites are good for excercising functionality and some error
conditions, but not always for reproducing real-world issues like
that, unfortunately.
Frankly I don't think this applies to the undef-warn-on-exit problem,
it's reproducable in a trivial cgi script. It must be something else i
Geoffrey Young wrote:
[...]
right, sorry. So it should be easy to revert in the previous code,
once we figure out what gets onto the stack when exit() is called (I'd
guess that it'll be undef).
according to perlapi, yes: for Perl_croak count is 1 and undef is on the
stack with G_EVAL.
so why n
Stas Bekman wrote:
Geoffrey Young wrote:
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?
well, I suppose DIR_MAGIC_TYPE and DECLINE_CMD are both strings, but
they managed to (somehow) work before.
I supp
Geoffrey Young wrote:
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?
well, I suppose DIR_MAGIC_TYPE and DECLINE_CMD are both strings, but
they managed to (somehow) work before.
I suppose, that's because we n
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?
well, I suppose DIR_MAGIC_TYPE and DECLINE_CMD are both strings, but they
managed to (somehow) work before.
other than that, if we declare that current_callback
Geoffrey Young wrote:
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 y
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 r
17 matches
Mail list logo
