Well, the caller is the C call that's, um, calling the perl code. As far as expectations go, I suppose initially that I naively expected Carp to report that, but of course that's not going to happen as it is.
Expectations aside, I would like to affect the same thing that Carp would normally do. The module is being used both from C and from Perl, so the solution must be general. Maybe I could subclass Carp so that it will report differently in the case of no call-stack (*now* maybe I'm answering my own question :^).
The whole thing with passing perl_parse() "/dev/null" feels less than clean as well. How is this normally handled?
Whatever I do, I was hoping to follow convention -- if there is any -- and that's why I'm laying this out here. What *do* folks do when they load_module() code that contains Carp? | [reply] |
I'm not sure I understand. Carp breaks? Or Carp doesn't return what you expect?
Disclaimer: I've never tried anything even remotely like this...
As far as I can tell from your example and other examples found on google, where you've put "/dev/null" is where others normally put the name of the calling file, which would be in keeping with the results returned by caller(). I could make an assumption (which is probably wrong), that my_argv as you've used it, would contain the package, file, line that would be returned by caller (and carp). Package defaulting to 'main' (as it's blank) and line defaulting to zero (as it's blank as well). Since my_argv is passed as a pointer, it may be that you can change the values before each call to call_method() in your C code, like say set the line number to the line number in your C code before making the call. Or it may be that the my_argv values are copied by perl_parse() and you can't change them later. But this is all purely speculation, take it for what it's worth.
| [reply] |