Date: Wed, 4 Jun 1997 16:30:06 -0700 (PDT) From: Bruce Evans <bde@zeta.org.au> To: freebsd-bugs Subject: Re: bin/3780: WEXITSTATUS() may return nagative value, which causes sh to generate bad $? Message-ID: <199706042330.QAA01825@hub.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/3780; it has been noted by GNATS. From: Bruce Evans <bde@zeta.org.au> To: FreeBSD-gnats-submit@FreeBSD.ORG, sanewo@ba2.so-net.or.jp Cc: Subject: Re: bin/3780: WEXITSTATUS() may return nagative value, which causes sh to generate bad $? Date: Thu, 5 Jun 1997 09:25:08 +1000 >BTW, should WEXITSTATUS() return unsigned value? (I don't know what POSIX says about this) WEXITSTATUS returns an 8-bit value, but is only valid on values return by wait(). sh corrupts these values by storing them in ps->status which has type short. This happens not to lose information under FreeBSD, but it causes some sign extension problems. When a process exits with the bogus status of -1, -1 first gets corrupted to 0xff. Then on 32-bit little-endian 2's complement machines, wait(&status) in the parent process stores 0xff00 in the int `status'. (short)0xff00 is (int)0xffffff00 and shifting this in WEXITSTATUS() gives (int)0xffffffff. POSIX.1 requires the arg to WEXITSTATUS() to be `the integer value pointed to by stat_loc'. I interpret this as saying that the arg must have integral type and the same value as the `int' that stat_loc once pointed to. I tried WEXITSTATUS((short)status) to test this, but the macro failed at compile time. The wait macros seem to be non-POSIX conformant in the non- _POSIX_SOURCE case because of the crufty (*(int *)&(w)) conversion doesn't work unless `w' is an lvalue of type `int'. sh also stores pids in variables of type short. This happens not to lose information under FreeBSD (because PID_MAX is 30000). Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199706042330.QAA01825>