Steffen Mueller (smuel...@cpan.org) writes:
> Check the C code generated by xsubpp. Then insert ludicrous amounts of
> printf()'s into the code that comes after the actual C++ function
> invocation.
I did consider that. But there is not much place for printf. This is how
it looks like:
RETVAL = executebatch(sqlsrv, rows_affected);
XSprePUSH; PUSHi((IV)RETVAL);
}
XSRETURN(1);
}
I assume these XSPrePUSH etc are macros, and if I generated the file
after pre-processing, there would be more place for printf. But I
ran out of steam there.
> Since you're passing around SV*'s the bug might be in the code that you
> wrote to handle the Perl datastructures if it's more than just a simple
> SvIV on rows_affected or SvPV_nolen() on sqlsrv. Sometimes, the time of
> destruction of "mortal"s may not be what you expect (generally during
> nextstate ops, though), so if you have a mortal SV that gets destroyed
> early... err. No. Then you typically get a segmentation fault, not an
> SV* that just happens to point at &PL_sv_undef. Nevermind my drivel. :)
About the only operation I do on sqlsrv is SvRV. The code for rows_affected
is
// Return rows_affected if required.
if (sv_rows_affected != NULL) {
sv_setiv(sv_rows_affected, rows_affected);
}
And it is not passed in any of the calls in the test.
Hm, I made a change in the calling code, and then hard-coded rows_affected
to be 4711 and added a tracing warn. Oh, no. Rows_affected is always
returned correctly. It's only RETVAL that gets the wrong value.
--
Erland Sommarskog, Stockholm, esq...@sommarskog.se
