Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!usc!zaphod.mps.ohio-state.edu!wuarchive!uunet!mcsun!ukc!pyrltd!root44!gwc From: gwc@root.co.uk (Geoff Clare) Newsgroups: comp.unix.programmer Subject: Re: Catching termination of child process and system() call Message-ID: <2612@root44.co.uk> Date: 19 Feb 91 17:03:18 GMT References: <1356@geovision.UUCP> <9882@dog.ee.lbl.gov> <2608@root44.co.uk> <12673:Feb1900:07:4691@kramden.acf.nyu.edu> Organization: UniSoft Ltd., London, England Lines: 52 In <12673:Feb1900:07:4691@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >In article <2608@root44.co.uk> gwc@root.co.uk (Geoff Clare) writes: >> The discussion does have some relevance to 'C' since >> it is about the format of the status returned by wait(), >No. It has absolutely nothing to do with C. We just happen to be talking >about it in C. I noticed you chopped off an important piece of text when quoting me. It referred to the system() function, which is defined by ANSI 'C'. A discussion of how the return value of system() is interpreted certainly is relevant to 'C', even if the discussion only involves how the value is interpreted on UNIX systems. Anyway, now the discussion has moved to comp.unix.programmer, there's no point in continuing the argument over whether it is relevant to comp.lang.c. >> POSIX does not specify the precise encoding of information in the status >> returned by wait(), system(), etc., so portable programs should not >> rely on the traditional encoding Chris describes above. Instead macros >> are provided in to extract the relevant data from the status: >Wrong. A program written according to your advice is decidedly >nonportable: it will work only on POSIX systems. A program written >according to Chris's advice will work under System V, BSD, and most >POSIX-based systems to boot. Someone who wants to plan for the future >should conditionally compile the POSIX code, though of course he'll >still have to use w & 0200 to get the core dump bit. If you re-read more carefully what I wrote, you'll realise you've done me an injustice. I said "portable programs should not *rely* on the traditional encoding Chris describes above." I did *not* say they should instead use *only* the POSIX macros, which is what you infer I said. A program which wants to be portable both to POSIX systems and to traditional systems would need to do something like this: #include #ifndef WIFEXITED #define WIFEXITED(s) (((s) & 0xff) == 0) #endif #ifndef WEXITSTATUS etc...... >Portability is defined by the real world, not a standards committee. The two are not mutually exclusive - the POSIX standards are a part of the real world. Widely portable programs need to allow for both POSIX systems and traditional systems. -- Geoff Clare (Dumb American mailers: ...!uunet!root.co.uk!gwc) UniSoft Limited, London, England. Tel: +44 71 729 3773 Fax: +44 71 729 3273