Follow-up Comment #8, bug #68064 (group groff):

At 2026-02-23T06:23:15-0500, cve wrote:
> Follow-up Comment #7, bug #68064 (group groff):
>
> I think we can close this issue, as it mostly stems from my incorrect
> understanding of the system libc function.
>
> I somehow had it differently in memory, namely that its return value
> is the return value of the executed comannd in a waitpid fashion,
> which is not the case.

I guess the correction to your recollection is the worst possible one:

You were neither right nor wrong, but _sometimes_ right.

(from man-pages 5.10):


RETURN VALUE
     The return value of system() is one of the following:

     *  If command is NULL, then a nonzero value if a shell is
        available, or 0 if no shell is available.

     *  If a child process could not be created, or its status could not
        be retrieved, the return value is -1 and errno is set to
        indicate the error.

     *  If a shell could not be executed in the child process, then the
        return value is as though the child shell terminated by calling
        _exit(2) with the status 127.

     *  If all system calls succeed, then the return value is the
        termination status of the child shell used to execute command.
        (The termination status of a shell is the termination status of
        the last command it executes.)

     In the last two cases, the return value is a "wait status" that can
     be examined using the macros described in waitpid(2).  (i.e.,
     WIFEXITED(), WEXITSTATUS(), and so on).


I'm inclined to leave this ticket open, though, as it's a big mystery
why Dave and I are getting different results from different versions of
groff.  Possibly other properties of our machines differ in ways that
affect the `system(3)` function's return value.  For instance, maybe our
respective "/bin/sh"s differ in ways that impact `system(3)`'s return
value and therefore the value of groff's `systat` register.  If so, that
fact might be worth a cautionary note in groff's Texinfo manual.

Or maybe /bin/false doesn't exist on his system, but is present on mine.
(I'm not sure there's a hard rule that says where a POSIX-conforming
"false" command has to be installed, as long as it's in the default
$PATH.)



    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?68064>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/

Attachment: signature.asc
Description: PGP signature

Reply via email to