> -----wrong-nil(!)-exit-status-----
> % nerr-cl.exe; echo $?
> 0
>
> $? cannot distinguish exit(0) from exit(-2) ... this is
> logical anarchy!
:) Ah, but those aren't just two different values passed to exit, they are
:) in fact two entirely different versions of the exit function: gcc links in
:) the version from newlib, whereas msvc links in the version from msvcrt.
What I meant was calling same msvcrt exit() with status = {0,-2} (in
nerr-cl.exe).
:) So the problem really is that the Windoze version of the exit function
:) isn't POSIX compliant. Still, we already knew that windoze != unix.
:) That's why cygwin exists, after all!
Right. Still, Cygwin could do better. See below.
:) Name one platform that *can* reliably test the exit status of binaries
:) that were written for a different platform? It's an achievement that it
:) can even run them.
Cygwin? When exit status is positive.
If one wrote:
% cat perr.c
int main()
{
exit (2);
}
she would get:
-----unsigned-8b-exit-status-----
% perr-cl.exe; echo $?
2
Isn't anybody finding weird that "positive exit status works fine from gcc and
cl" i.e. $? can always (gcc or cl) distinguish exit(0) from exit(2)? What I
meant with "reliably".
Isn't the same int exit status being set from mscvrt to 0xfffffffe (nerr-cl.exe)
and 0x00000002 (perr-cl.exe)?
Where does $? = 2 come from?
> ksh :) yields the same Cygwin bug.
:) Don't blame me!
Never meant to. Cheers, daniel.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
