Why is Perl 5.14 using (0+GvGP(gv)->gp_cv) definition for GvGC?

Question

I'm doing some kind of research related to mod_perl-Apache-Perl compatibility. Recently I tried to build mod_perl 2.0.4 using Perl 5.14.2. The compilation phase was terminated prematurely with an error:

modperl_perl.c: In function ‘modperl_perl_core_global_init’:
modperl_perl.c:58:9: error: lvalue required as left operand of assignment

In this place the following code is written:

    GvCV(gv) = get_cv(cglobals->sub_name, TRUE);

Searching for what could generate this error, I have found a difference between previous versions of Perl and Perl 5.14 (CORE/gv.h):

    #define GvCV(gv) (GvGP(gv)->gp_cv)   /* previous versions */

vs

    #define GvCV(gv) (0+GvGP(gv)->gp_cv)  /* in Perl 5.14 */

Removing this 0+ from the definition allows mod_perl 2.0.4 to be compiled successfully, and this is fine because 0+... is not recognized as an lvalue compared to previous versions.

Why is 0+ used in the definition of GvCV and is it necessary? or is it safe to remove it and have the definition of GvCV(gv) like in previous versions of Perl?

Answer 1

The commit that pushed this change is this one.

Short log:

add GvCV_set() and GvGP_set() macros.

and make GvCV() and GvGP() rvalue-only.

This it to allow a future commit to eliminate some backref magic between GV and CVs, which will require complete control over assignment to the gp_cv slot.

So the purpose of that 0+ is precisely to make those macros rvalues. You'd be better off waiting for mod_perl to update its code to match the new semantics, because reverting thos macros will be invalid at some point. (I don't know if that "future commit" is already implemented or not.)

Related discussion: http://www.nntp.perl.org/group/perl.perl5.porters/2011/01/msg167682.html