From owner-freebsd-hackers Wed Apr 24 17:46:58 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA19705 for hackers-outgoing; Wed, 24 Apr 1996 17:46:58 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id RAA19629 for ; Wed, 24 Apr 1996 17:46:37 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id KAA29532; Thu, 25 Apr 1996 10:44:43 +1000 Date: Thu, 25 Apr 1996 10:44:43 +1000 From: Bruce Evans Message-Id: <199604250044.KAA29532@godzilla.zeta.org.au> To: jraynard@dial.pipex.com, julian@ref.tfs.com Subject: Re: Flaws in system() implementation? Cc: hackers@FreeBSD.org Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >> > 1. Use of a wait union when an int would do. >> This is the correct POSIX thing to do.. >> check the man page for wait. >According to the 2.1.0-RELEASE man page, wait and friends use an int* >for the status variable. That is the correct POSIX thing. >> > 3. Returns 0 if fork() fails, when -1 seems more appropriate. >> POSIX says: >Thanks for posting this, I don't have access to any POSIX specs >(except the odd snippet in books). What's the best way of getting hold >of them? Joerg said that the draft POSIX spec is on the (old) WC Internet Info cdrom. I haven't got it. >> If "command" is a null pointer, the system() function returns non-zero >> only if a command processor is available. >OK (Out of interest, what kind of circumstances would result in a >command processor not being available?) Non-POSIX ones. system((char *)NULL) is about the only aspect of system() that is specified by ANSI. It returns 0 to tell you that system() is completely useless on the current system :-). >> If a child process cannot be created, >> or if the termination status of hte command interpretter cannot be obtained >> system() returns -1 >> and sets errno to indicate the error. >Doesn't that imply that system() should return -1 if fork() fails? >(Forgive me if I'm being obtuse, I'm not very experienced at reading >standardese). It's less ambiguous than julianese :-). It completely specifies the return value after a fork failure, at least in my copy, which says "shall return -1" instead of "returns -1". "shall" is standardese that means that the implementation is non-conforming if it does anything else. "should" would allow the implementation to screw up. Bruce