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

Re: perl's internal usage of dTHX; is a bad idea

Thread Previous
From:
Nick Ing-Simmons
Date:
October 26, 2003 11:00
Subject:
Re: perl's internal usage of dTHX; is a bad idea
Message ID:
20031026185945.7855.6@llama.ing-simmons.net
Stas Bekman <stas@stason.org> writes:
>Nick Ing-Simmons wrote:
>> Stas Bekman <stas@stason.org> writes:
>> 
>>>Frankly I don't understand why internally Perl uses functions which aren't 
>>>prototyped with (pTHX_ ...), and call dTHX; instead. 
>> 
>> 
>> XS module API compatibility.
>
>Yes, but I'm talking about internal calls (not XS) that have my_perl, but not 
>passing it because the callee doesn't accept one (Perl_safesysmalloc is one of 
>those).

That is because "almost everywhere" Perl_safesysmalloc() is malloc()
and OS's malloc()s do not take pTHX.
Win32 with weird perlhost.h C++ hackery is an exception.

>
>If all internall perl calls were never to use dTHX, PERL_SET_CONTEXT() won't 
>be needed.
>
>> Most of API _does_ pass aTHX (usually via a macro).
>> An up-to-date list of those that don't would be welcome, there 
>> may now be few enough to replicate those and lead XS writers in 
>> that direction.
>
>Anybody has an idea of doing this programmatically? Using a simple C code 
>parser that returns all functions that call dTHX and its variants?

You could try preprocessing everything then looking for something in dTHX 
expansion.



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