[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

os/2 child process status [was: snapshot in preparation for m4 1.4.12]

From: Eric Blake
Subject: os/2 child process status [was: snapshot in preparation for m4 1.4.12]
Date: Sun, 10 Aug 2008 22:26:44 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20080708 Thunderbird/ Mnenhy/

Hash: SHA1

According to Elbert Pol on 8/7/2008 12:09 PM:
| But with the make -k check there are some errors.
| I attach the check.log
| This is with os/2

Finally, it looks like your system(3) command gives unusual exit statuses
for child processes.  I still haven't taken the leap to use gnulib's
execute module, which might help matters here.  The two failures in this
category are:

| Checking ./178.sysval
| -2
| +65280

Here, the sysval macro after syscmd(`exit 2') is reporting that the child
process died abruptly from signal 255 (255<<8 == 65280; m4's sysval macro
shifts the status of child processes that die from signals in order to
distinguish from normal exit).  That seems rather fishy - generally there
is no signal 255.  On your platform, is there a way to force a child
process in system(3) to exit with a known normal exit value?  Do you need
us to help you write a simple C program that compares system, popen, and
fork/exec/wait for the various child status detection behaviors?

| Checking ./182.mkstemp
| -1
| +256

Testsuite bug; I'll have to patch doc/m4.texinfo.  Basically, I cannot
assume that a failed 'test -f foo-*' exits with status 1, only that it
exits non-zero.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


reply via email to

[Prev in Thread] Current Thread [Next in Thread]