Is there a way to access special tokens in perl from XS?

Question

In perl special tokens like __PACKAGE__, __SUB__, __FILE__, __LINE__ exists and available from script.

I may get value of __PACKAGE__ from XS as HvNAME( PL_currstash ), I suppose.
But how to access others?

Is there special interface to access all of them from XS? Like: CTX->package, CTX->sub etc.

Anaplasty

What do you mean for perl from XS ? I don't understand your question, please explain. – Trichomoniasis

@F.Hauri in perl you may write C code. To simplify C<->Perl interaction there is XS mechanism exists. I ask how to access token __SUB__ from XS – Anaplasty

In the book Perl Developer's Dictionary page 267 it says that the tokens __LINE__ and __FILE__ are replaced at compile time. See more here – Equitant

Rather PL_curstname for the package name, no? (I'm not sure about it, but from what I read in intrpvar.h, it seems more like it. Have a look at this file, and at embedvar.h as well, it could help you find what you are looking for. – Smallsword

As @HåkonHægland said, __LINE__ and __FILE__ are replaced at compile time. However, you should still be able to get informations about the line or file, since when a die happens for instance, Perl tells you what line/file it happen at. I'd suggest you have a look in Perl sources, especially what happens when there is a die (for instance because of a division by 0). Not sure it will show you what you're looking for, but that's how I'd do it. – Smallsword

@Smallsword I believe that __FILE__, __LINE__ is stored at COP (PL_curcop/PL_op). __SUB__ is accessable as OP->cv->name... The question is not about how to access this data, but about accessing this data through some special interface – Anaplasty

So I assume CopFILE and CopLINE macros are not what you are looking for? (sorry if I don't quite understand your question; I don't write XS code, I just play with Perl sources now and then) – Smallsword

Those are Perl operators, so you can't call them except from Perl code. You can surely find the file and line number of the statement that called your XS sub, though, since caller does it. – Rooker

Answer 1

You can look them up one by one in toke.c for the compile-time values:

• __PACKAGE__ => HvNAME(PL_curstash) or PL_curstname
• __FILE__ => CopFILE(PL_curcop) (at compile-time)
• __LINE__ => CopLINE(PL_curcop) (at compile-time)
• __SUB__ => PL_compcv

If you need them at run-time look at the various data fields available in the context caller_cx and current sub (cv). There's no context struct as in parrot or perl6 passed around, rather a stack of active context blocks.

Hale

Answer 2

Perl subroutines are represented in C with type CV. The CV for the XSUB is passed in the cv argument:

#define XSPROTO(name) void name(pTHX_ CV* cv)

You can get the name of the XSUB with GvNAME(CvGV(cv)). This is especially useful if you register an XSUB under multiple names, for example with the ALIAS or INTERFACE keywords, or in typemaps.

To get the current stash (__PACKAGE__ equivalent), I'd suggest to use CvSTASH(cv).

__FILE__ and __LINE__ are provided by the C compiler as macro.

Consolute

Answer 3

The C equivalent to __FILE__ is __FILE__.

The C equivalent to __LINE__ is __LINE__.

The C99 equivalent to __SUB__ is __func__. There wasn't anything standard before.

There's no C equivalent to __PACKAGE__ because C doesn't have namespaces.

That said, I don't think you want information about the current line of execution; I think you want information about the XS sub's caller. That means you're actually asking for the XS equivalent of caller.

The XS equivalent of caller is caller_cx. Looking at Perl_cx_dump in scope.c should give an idea how to use the returned PERL_CONTEXT structure.

Rooker

Why are you posting a copy-and-paste answer, one directly copied from your previous answer? – Salary

Then it would probably be better for you to figure out which one should be closed, and vote on that, no? Or at least post a comment linking your prior answer, since it's not felt to be correct to copy and paste answers -- at least each time I've seen moderators handle this (and they have software to identify this), they usually delete one or both answers. – Salary

Because I'm not a PERL expert. Regardless, we'll let the moderators decide. – Salary

@Hovercraft Full Of Eels, I didn't know about this question when I answered the other. – Rooker

Again, it's no never mind to me. We have a plagiarism detector running (which is how I was flagged to this answer and its dup), and so the moderators will find the duplicates and handle them, if you don't handle them yourself. – Salary

@Hovercraft Full Of Eels, The other question will get closed as a dup, but I'm not going to hurry that close a question as a duplicate of one that didn't have an answer. – Rooker

More problematic is that 5 of 6 paragraphs of this are wrong. – Hale

@rurban, Really??? That's a very harsh assessment. Fixed to use more precise wording. – Rooker