develooper Front page | perl.perl5.porters | Postings from December 2017

Re: [perl #2754] [BUG] can't exit 0 from CHECK{}

Thread Next
From:
Zefram
Date:
December 10, 2017 22:17
Subject:
Re: [perl #2754] [BUG] can't exit 0 from CHECK{}
Message ID:
20171210221702.GD25404@fysh.org
Oh boy, this was a fun one.  The basic problem is that the return value
from perl_parse() is overloaded.  Is it a truth value or an exit code?
If an exit code, is it a Unix-style exit code or a native exit code?
The perlembed tutorial disagreed with perlmain.c and had a bunch of flaws
that mark it as an unreliable source, and the function wasn't actually
documented other than by reference to perlembed.

We can preserve most of the overloaded use of perl_parse()'s return value
by the very simple expedient of returning 0x100 for a zero exit code,
leaving an actual zero return value to indicate that we're not exiting.
On Unix this is a total fix.  On other OSes an equivalent trick might be
possible, but might not, depending on local conventions for exit codes.
(It's clear enough that perl_parse()'s return value has the significance
of a native exit code, despite the Unix-centric assumptions that crept
in.)  It should in any case return non-zero for a zero native exit code
regardless of platform: that means that an exit with zero native exit
code will at least always be interpreted as exiting, so the remaining
misbehaviour will only consist of exiting with the wrong exit code.

For users to get the correct exit code they need to interpret
perl_parse()'s return value the way perlmain.c does: as a truth value,
with the actual exit code coming from perl_destruct().  perlembed needs
to show this mode of usage.

I have done all this (and some more) in commit
0301e899536a22752f40481d8a1d141b7a7dda82.  That resolves this ticket.

-zefram

Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About