I think it's just intended to explain the action - ie. that $v{timep}
has been set to ST(1), also possibly as an example of how to debug
this type of %v usage (which I've never used).
>
> - the 'SvOK(ST(1)) ? ...' is just sitting in void context; it is not
> assigned to anything.
I think it's just a bug in the example.
> It's really difficult to guess the original intent of the example in order
> to know how to fix it. Was the result of that tertiary conditional
> supposed to have been assigned to host? So is it trying to say:
> 'if timep is undef, set host to NULL? The man page for rpcb_gettime()
> says that a NULL host implies localhost. But I don't see why passing an
> undef timep SV should make it default to localhost and override the host
> variable.
I suspect here they're taking the function used in several examples
(rcpb_gettime()) and tried to build a new example for %v out of it,
even though the example doesn't match how rcpb_gettime() is used.
>
> So, questions:
>
> What should I do to fix this; i.e. what to do about %v?
>
> If we want to keep it, we need to:
>
> - either re-add "use vars '%v'" to the code, or update the docs to tell
> people to use %::v rather than %v. For the former, it means that any XS
> code using %v wont work between 5.10.0 and 5.38.0.
EU::PXS is dual-life, if we do re-allow %v they can depend on a
sufficently recent release of EU::PXS.
> - We will also need to fix the code example involving rpcb_gettime() and
> %v. To do that, we need to agree on what the code example was actually
> %trying to do, or come up with a different code example.
>
> The other option is to remove mentions of %v from perlxs.pod - both the
> stating of what it is, and the example code. (It doesn't involve actually
> removing the facility, since the facility already isn't there, apart from
> in the general sense that any code in the XS file which gets evaled can in
> principle get or set any global var, %v or otherwise).
>
> My vote is to get rid of it.
I think so too.
Tony