Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!columbia!rutgers!sri-spam!mordor!lll-tis!ames!oliveb!sun!gorodish!guy From: guy%gorodish@Sun.COM (Guy Harris) Newsgroups: comp.unix.questions Subject: Re: Fork and Join, Pipe in C Message-ID: <22636@sun.uucp> Date: Thu, 2-Jul-87 21:33:51 EDT Article-I.D.: sun.22636 Posted: Thu Jul 2 21:33:51 1987 Date-Received: Sat, 4-Jul-87 11:00:05 EDT References: <7737@brl-adm.ARPA> <1186@ius2.cs.cmu.edu> <8174@utzoo.UUCP> <1764@oliveb.UUCP> Sender: news@sun.uucp Lines: 73 > Guy is posting from Sun and they are the ones who are always having > problems with null pointer dereferencing. Somebody writes code that > runs fine on a Vax but core dumps on a sun. The customer's response is > that Sun does not have a good port because the software ran perfectly on > a Vax. Sun responds that the code is broken but the Vax just didn't > catch it. Nobody is happy but DEC. Plenty of other people have these problems as well. Code that makes a lot of invalid assumptions will run "perfectly" (or, at least, run without any *obvious* errors; there have been postings in comp.lang.c that indicate that some such programs do *not* run fine, they just don't drop core) on a VAX (running one of the common versions of VAX UNIX; a version done inside BTL disallowed null pointer dereferencing, and VMS does also) and blow up on any of a number of machines out there. The only way to get a machine that will run all the code that runs on your current VAX is to get another VAX of the same sort. No, just buying another VAX isn't good enough. Take a look at the "comet sucks" comment in the VAX 4BSD "doprnt.c" (which, despite the ".c" suffix, is assembler code). That was a case where the VAX architecture manual said "don't do this" but somebody went ahead and did it anyway, and sure enough it didn't work when it ran on a 750. When a document says "don't do this", like the "vfork" manual page does, you should take it seriously unless you have an EXTREMELY good reason not to and are prepared to take the consequences. In the case of null pointers, K&R says that null pointers are "distinguishable from a pointer to any object", which means there is no guarantee what you get when you dereference one; this should at least act as a suggestion not to use pointers if they might be NULL without checking first. (Fortunately, ANSI C is a bit more firm on this point, for the benefit of people who don't get the hint.) You may get a null string, you may get "f(", you may get something with "p&P6" in it (or whatever the PDP-11 UNIX C implementation stuffed down at location 0), or you may get a memory fault. The point here is that some of us have learned that "this program works on machine X with C compiler Y with version Z of operating system W under the circumstances we tried it on" is very different from "this program is correct", or even "this program is reasonably close to correct". It is extremely galling when developers blame *their* bugs on the vendor of a system just because that system doesn't have all the implementation quirks of the system they were using before: it's not (little|big)-endian, it doesn't have a zero byte at location zero, it doesn't allow odd-boundary references to datatypes longer than 1 byte, it doesn't have _NFILE in , etc., etc., etc.. They *could* have gotten it right, but didn't. > My opinion is that they shouldn't have a vfork unless they can implement > it in a way that is compatible. The memory sharing characteristic is a > documented and demonstrably used feature of vfork. It is also a characteristic that the manual specifically says should NOT be used. > It was my understanding that, after a COW fork was implemented, vfork > would disappear, not be maintained as an alternate name for fork. I quote from the manual page: This system call will be eliminated when proper system sharing mechanisms are implemented. Users should not depend on the memory sharing semantics of "vfork" as it will, in that case, be made synonymous to "fork". This reads as if it were saying that the *mechanism* that implements "vfork" will go away, but that the *interface* will remain as a synonym for "fork", so that correctly-written programs will still work. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com