Mailing List Archive

Dead global variables?
I may have this wrong so I'm asking.

I can find nothing referring to PL_revision, PL_version, or PL_subversion anywhere in perl or CPAN. I don't think there are circumstances where you can reference them as revsion/version/subversion. Does this mean they are unused and could be removed?

Todd
Re: Dead global variables? [ In reply to ]
On Fri, 31 Jul 2020 23:58:54 -0500
Todd Rinaldo <toddr@cpanel.net> wrote:

> I may have this wrong so I'm asking.
>
> I can find nothing referring to PL_revision, PL_version, or
> PL_subversion anywhere in perl or CPAN. I don't think there are
> circumstances where you can reference them as
> revsion/version/subversion. Does this mean they are unused and could
> be removed?

It sounds like they're probably dead and could be removed then.

But I would suggest not doing so yet, as they're hardly in the way of
anything currently. We should keep the giant "bump version to 7"
changes as small as technically possible, so if things do break it will
be easier to unpick why. We can remove those dead variables later on
when the 7 part is settled.

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Re: Dead global variables? [ In reply to ]
> On Aug 1, 2020, at 6:55 AM, Paul LeoNerd Evans <leonerd@leonerd.org.uk> wrote:
>
> On Fri, 31 Jul 2020 23:58:54 -0500
> Todd Rinaldo <toddr@cpanel.net> wrote:
>
>> I may have this wrong so I'm asking.
>>
>> I can find nothing referring to PL_revision, PL_version, or
>> PL_subversion anywhere in perl or CPAN. I don't think there are
>> circumstances where you can reference them as
>> revsion/version/subversion. Does this mean they are unused and could
>> be removed?
>
> It sounds like they're probably dead and could be removed then.
>
> But I would suggest not doing so yet, as they're hardly in the way of
> anything currently. We should keep the giant "bump version to 7"
> changes as small as technically possible, so if things do break it will
> be easier to unpick why. We can remove those dead variables later on
> when the 7 part is settled.
>

I'm only thinking of this as a 7.2 or future change. Nothing to do with 7.0.0 or 7.1.0

Todd
Re: Dead global variables? [ In reply to ]
On Fri, Jul 31, 2020 at 11:58:54PM -0500, Todd Rinaldo wrote:
> I may have this wrong so I'm asking.
>
> I can find nothing referring to PL_revision, PL_version, or
> PL_subversion anywhere in perl or CPAN. I don't think there are
> circumstances where you can reference them as
> revsion/version/subversion. Does this mean they are unused and could be
> removed?

From the comments in perl.h added by Nicholas C in 2011:

/* These are baked at compile time into any shared perl library.
In future releases this will allow us in main() to sanity test the
library we're linking against. */

So I guess we could potentially make use of them in future.

--
Lear: Dost thou call me fool, boy?
Fool: All thy other titles thou hast given away; that thou wast born with.
Re: Dead global variables? [ In reply to ]
Paul "LeoNerd" Evans wrote:
> On Fri, 31 Jul 2020 23:58:54 -0500
> Todd Rinaldo <toddr@cpanel.net> wrote:
>
>> I may have this wrong so I'm asking.
>>
>> I can find nothing referring to PL_revision, PL_version, or
>> PL_subversion anywhere in perl or CPAN. I don't think there are
>> circumstances where you can reference them as
>> revsion/version/subversion. Does this mean they are unused and could
>> be removed?
>
> It sounds like they're probably dead and could be removed then.
>
> But I would suggest not doing so yet, as they're hardly in the way of
> anything currently. We should keep the giant "bump version to 7"
> changes as small as technically possible, so if things do break it will
> be easier to unpick why. We can remove those dead variables later on
> when the 7 part is settled.
>

The vars should be kept. You have to know what perl.so or /bin/perl is
running for XS module reasons, my XS handshake code does the check in a
nearly static CPP way, but there might be other 1 off "what libperl.so
is this?" code written by a dev who can't figure out which perl is
running by what web server on what container and he doesn't have strace.