Re: plperl fails with perl 5.28

Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
> On 05/22/2018 07:18 AM, Christoph Berg wrote:
>> plperl fails to install with perl 5.27.11, which is to be released as 5.28.0:

> I have a tiny bit more info:
>     andrew=# load 'plperl.so';
>     ERROR:
>     CONTEXT:  while running Perl initialization
>     andrew=#

I get the same behavior with a build of 5.27.11 on Fedora 28.

> That means it's failing at line 860 of plperl.c.

Tracing through it, the problem is that perl_run is returning 0x100,
rather than zero as we expect, even though there was no failure.
This happens because perl.c:S_run_body() falls off the end of the
initialization code and does "my_exit(0);".  Apparently it's done that for
a long time, but what's new is that perl_run() does this in response
after catching the longjmp from my_exit():

        if (exit_called) {
            ret = STATUS_EXIT;
            if (ret == 0) ret = 0x100;
        } else {
            ret = 0;
        }

That traces to this recent commit:

https://perl5.git.perl.org/perl.git/commitdiff/0301e899536a22752f40481d8a1d141b7a7dda82

which seems rather brain-dead from here, because it claims that it's
defining perl_run's result as a truth value, which it is not any more.

So assuming that this holds and the Perl guys don't see the error
of their ways, we'd need something like this, I think:

-        if (perl_run(plperl) != 0)
+        if ((perl_run(plperl) & 0xFF) != 0)

but TBH I think someone oughta file a bug report first.  They can't
seriously intend that callers must do that, especially when there does
not seem to be any big bold warning about it in perl*delta.pod.

(Also, since perl_parse and perl_run are now specified to have identical
return conventions, we'd probably want to change the perl_parse call
likewise, even though it's not failing today.)

(Alternatively, perhaps it's a bad idea that the plperl initialization
script falls off the end rather than explicitly returning?)

            regards, tom lane