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

Re: [PATCH] Support B::Generate and B::C

Thread Previous | Thread Next
July 5, 2012 01:30
Re: [PATCH] Support B::Generate and B::C
Message ID:
On 4 September 2010 01:26, Ben Morrow <> wrote:
> Quoth (Jim Cromie):
>> As yet, I dont know whether/how synthesized targets are rendered
>> distinctly from targets that are already there, further elucidation
>>  on the exact meaning of [t3] in the following would be welcome.
>>            % perl -MO=Concise,-exec -e '$a = $b + 42'
>>            1  <0> enter
>>            2  <;> nextstate(main 1 -e:1) v
>>            3  <#> gvsv[*b] s
>>            4  <$> const[IV 42] s
>>         *  5  <2> add[t3] sK/2
> It means the add op has a target, which is at index 3 in the pad, which
> is SVs_PADTMP. pp_add uses it to store the result it is going to return.
>> Can we find agreement on what should/must be there for X functions ?
> IMHO there should be no such functions, except in exceptional
> circumstances where nothing else will work. They should *never* be
> (directly) called by random CPAN extensions, except as part of a
> backcompat hack that is only invoked on versions of perl known to have
> exported the function with the desired semantics. Noone gets to complain
> if they have been linking against X functions and they suddenly
> disappear, or suddenly start doing something quite else (nasal demons 'n
> all that).

Just a note that some X functions are so denoted because they are
private to perl but must be accessable from the debug engine.


perl -Mre=debug -e "/just|another|perl|hacker/"

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