develooper Front page | perl.perl5.porters | Postings from July 2019

Re: #define PERL_EXT to get feature test macros

Thread Previous
From:
ilmari
Date:
July 22, 2019 20:15
Subject:
Re: #define PERL_EXT to get feature test macros
Message ID:
d8jsgqxu8q2.fsf@dalvik.ping.uio.no
"Paul \"LeoNerd\" Evans" <leonerd@leonerd.org.uk> writes:

> There's some handy macros in feature.h that define useful tests like
>
>     if (!FEATURE_SIGNATURES_IS_ENABLED)
>         Perl_croak(aTHX_ "Experimental subroutine signatures not enabled");
>
> If I do something like this then I can use them in an XS module:
>
>   #define PERL_EXT
>   #include "feature.h"
>
> Is that a good idea?

PERL_EXT is for core extensions (XS modules under ext/), so doing that
is almost as naughty as defining PERL_CORE in a CPAN module (which is
more common on CPAN┬╣).  However, since you're only doing this for
already-released versions, it's unlikely to break in practice.

[1]:
https://grep.cpanauthors.org/search?q=%22define+PERL_CORE%22&extension=xs&extension=h
https://grep.cpanauthors.org/search?q=%22define+PERL_EXT%22&extension=xs&extension=h
     

> If not, could it become one somehow? It'd be useful to have a nice way
> for XS modules (especially those implementing syntax features) to
> easily query such state. Without this I'd have to do quite a bit of
> copy-pasting from internals to get the same effect.

We have documented APIs for checking warning categories, both in XS
(https://perldoc.pl/perlapi#Warning-and-Dieing), and Perl
(https://perldoc.pl/warnings#Reporting-Warnings-from-a-Module), so I
don't see why features shouldn't have something equivalent.

Well volunteered (again)!

- ilmari, *g,d&r*
-- 
"I use RMS as a guide in the same way that a boat captain would use
 a lighthouse.  It's good to know where it is, but you generally
 don't want to find yourself in the same spot." - Tollef Fog Heen

Thread Previous


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About