std-unix@ut-sally.UUCP (Moderator, John Quarterman) (11/04/86)
From: gwyn@brl.arpa (VLD/VMB) (Douglas A. Gwyn) Date: Mon, 3 Nov 86 11:31:40 EST getopt() -- this would depend on adoption of the AT&T "command language syntax standard", which is in the domain of 1003.2. This may happen. curses -- this lies outside the scope of X3J11 and 1003.1. It would perhaps be worth standardizing in some other 1003.n working group. popen() -- this was discussed by X3J11 and excluded, on the grounds that non-UNIX vendors would find themselves under pressure from customers to make popen() useful rather than just a stub, and the inability to do this would lead to unhappiness. Similar arguments against system() were somewhat weaker, and although its return value semantics were reworked, system() survived since it is implementable in a non-trivial way far more often than popen(). I don't know what problems Mark could have with <memory.h>, since it isn't in the X3J11 draft proposed standard, nor with memccpy(), which doesn't exist. If he meant memcpy(), X3J11 permits SVID semantics for that now. (The previous "Rob Pike special" is also defined, under the name memmove(), since there was no consensus for preferring either of the two possible specifications for the function. I suspect in many implementations memmove() and memcpy() will be synonymous.) P.S. The X3J11 draft proposed standard intended for public review and comment has been printed, but has to receive some sort of official approval (X3?) before it is actually sent out to the public. This will take something like a month longer than originally anticipated, as I understand it. Patience! Volume-Number: Volume 8, Number 28