Front page | perl.perl5.porters |
Postings from November 2008
If I counted correctly, there are 13 modules on CPAN which define PERL_CORE
when compiling their C (or XS) code.
Seven of these are easy:
Acme-NabeAtzz/NabeAtzz.xs:1:#define PERL_CORE
Acme-PerlVMGolf/PerlVMGolf.xs:1:#define PERL_CORE
Devel-Pragma/Pragma.xs:1:#define PERL_CORE
Goto-Cached/Cached.xs:1:#define PERL_CORE
autobox/autobox.xs:1:#define PERL_CORE
mysubs/mysubs.xs:1:#define PERL_CORE
These all do nothing, and seem superfluous. I suspect that the author copied
this part of the XS code from somewhere else.
The remaining 6 group as follows:
CGI-SpeedyCGI/src/speedy_inc_perl.h:21:# define PERL_CORE
PersistentPerl/src/perperl_inc_perl.h:21:# define PERL_CORE
The only reason appears to be to link to Perl_setdefout()
EXp |void |setdefout |NULLOK GV* gv
void
Perl_setdefout(pTHX_ GV *gv)
{
dVAR;
SvREFCNT_inc_simple_void(gv);
if (PL_defoutgv)
SvREFCNT_dec(PL_defoutgv);
PL_defoutgv = gv;
}
It hasn't materially changed in years. Seems best to document it and make part
of the API.
Data-Alias/Alias.xs:9:#define PERL_CORE
Data-PostfixDeref/PostfixDeref.xs:1:#define PERL_CORE
Data::Alias Wants DO from perly.h, Data::PostfixDeref wants ARROW from perly.h
Currently they're protected by an #ifdef PERL_CORE
I don't think that we can make them unconditionally declared, as the names
will clash. But is it sane to make them exposed by another documented #define?
For perl pre-5.9.2, Data::Alias also wants:
EXp |OP* |pop_return
but pre-5.9.2 isn't changing so that's not relevant.
Data-PostfixDeref/thieved.c:6:#define PERL_CORE
This seems to be superfluous. (I removed it; it still compiled and passed
tests)
Devel-BeginLift/BeginLift.xs:1:#define PERL_CORE
This wants to link to Perl_linklist()
p |OP* |linklist |NN OP* o
Is it stable enough to expose?
Class-MethodCache/MethodCache.xs:2:#define PERL_CORE
Class-MethodCache/MethodCache.xs:5:#undef PERL_CORE
The code is:
/* BLECH!!!! needed for HvMROMETA */
#define PERL_CORE
Whilst HvMROMETA is defined always, it uses Perl_mro_meta_init(), which is
not part of the public API. However, it's accessing a struct described as:
/* Subject to change.
Don't access this directly.
*/
struct xpvhv_aux {
...
}
So I'm not sure. It's actually only interested in exposing
C<HvMROMETA(stash)->cache_gen>, but I'm pretty sure that that *isn't*
intended to be public.
Faster/Faster.pm:678:#define PERL_CORE
The regression tests are minimal, so I can't confidently say what its
effects are. Moreover, there has only been 1 CPAN release ever, in March 2006,
and there doesn't appear to have been any activity since then. I'm also not
sure whether the approach it takes requires access to the core's C source
code too, hence it isn't really going to be affected by locking down the
extension API for XS code.
So it looks like there are precisely 4 questions to answer:
1: Perl_setdefout()
2: constants in perly.h
3: Perl_linklist()
4: HvMROMETA()/Perl_mro_meta_init()/struct xpvhv_aux/cache_gen
Nicholas Clark
Thread Next