Hello John,
John Gardner wrote on Thu, Oct 15, 2026 at 01:05:03PM +1100:
> G. Branden Robinson wrote:
>> At 2026-10-14T20:12:37+0200, Bruno Haible wrote:
>>> It is strange that the error is:
>>> mmroff: fatal error: "./groff -rRef=1 -z -mm -t -T utf8 -P -cbou
>>> ../contrib/mm/tests/artifacts/use-reference.mm" exited with status 4096
>>> I thought that the maximum portable exit status in POSIX was 127
>>> (or 255, if you allow process termination by signal).
Looking at POSIX, i don't see that it handles the bit 0x80 (= 128)
of the exit(3) argument in any special way. It's only the shell
that uses values of 126 and greater in special ways, but no shell
is involved here.
>> It's the return value of Perl's `close()`.
That's not entirely accurate; it isn't the *return value* of close(3p),
but the value that close(3p) stores into the perlvar(1) $? variable,
which perlvar(1) documents as follows:
$CHILD_ERROR
$? The status returned by the last pipe close, backtick (``)
command, successful call to wait(3p) or waitpid(3p), or from
the system(3p) operator. This is just the 16-bit status word
returned by the traditional Unix wait(2) system call (or else
is made up to look like it). Thus, the exit value of the
subprocess is really ($? >> 8), and "$? & 127" gives which
signal, if any, the process died from, and "$? & 128" reports
whether there was a core dump.
For details, also look at "perldoc -f close".
>> It'd probably be a good idea to clarify this diagnostic message.
Indeed. End users of mmroff(1) should not be expected to be familiar
with how the Perl language handles IPC wrapping of Unix system calls,
nor would it be obvious to users of mmroff(1) that this error
message is related to internal Perl IPC mechanics at all.
>>> I thought that the maximum portable exit status in POSIX was 127
>>> (or 255, if you allow process termination by signal).
> Trying to set an exit code greater than 0xFF will just return the value
> modulo 256, which makes the exit status of 4096 so interesting:
Both of you are confusing POSIX exit(3) and wait(2) - but admittedly,
the message from mmroff(1) provides no hint it is talking about wait(2),
nor should it say so, nor should it be talking about wait(2) in the
first place.
Yours,
Ingo
