develooper Front page | perl.perl5.porters | Postings from September 2003

Perl_foo vs. foo perl API in documentation

Thread Next
Stas Bekman
September 29, 2003 16:39
Perl_foo vs. foo perl API in documentation
Message ID:
Finally I had a chance to read the whole new perldelta for 5.8.1. This para is 
not so clear to me:

Certain Perl core C APIs like C<Perl_list> are no longer available
without their C<Perl_> prefix.  If your XS module stops working
because some functions cannot be found, in many cases a simple fix is
to add the C<Perl_> prefix to the function and the thread context
C<aTHX_> as the first argument of the function call.  This is also how
it should always have been done: letting the Perl_-less forms to leak
from the core was an accident.  For cleaner embedding you can also
force this for all APIs by defining at compile time the cpp define

But anybody who wants to use perl API has to read perlapi.pod, which doesn't 
use the Perl_ prefix in most cases. And sometimes it's inconsistent, e.g. for 
Perl_form the entry mixes the two:

       form    Takes a sprintf-style format pattern and conventional (non-SV)
                arguments and returns the formatted string.

                    (char *) Perl_form(pTHX_ const char* pat, ...)

I'm sure that other pods use a lot of short forms as well.

So it's not surprising that non-core developers are using the short form in 
their XS/embedding code. IMHO, it's not not leaked from the core, it's 
"endorsed" by perl's own documentation. Unless I miss something obvious here.

Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker     mod_perl Guide --->

Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About