Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84 SMI; site sun.uucp Path: utzoo!utcs!lsuc!pesnta!amdcad!decwrl!sun!shannon From: shannon@sun.uucp (Bill Shannon) Newsgroups: net.lang.c Subject: Re: lint, pointers, 0 (what else?) Message-ID: <1982@sun.uucp> Date: Fri, 8-Feb-85 01:59:15 EST Article-I.D.: sun.1982 Posted: Fri Feb 8 01:59:15 1985 Date-Received: Fri, 8-Feb-85 15:24:07 EST References: <366@harvard.ARPA> <8077@brl-tgr.ARPA> <425@rlgvax.UUCP> Distribution: net Organization: Sun Microsystems, Inc. Lines: 27 > Also, another point on type-correctness: even on a Motorola 68000 > implementation with 32-bit "int"s, you can lose if you don't declare > functions which return pointers. See the article in the Dallas USENIX > proceedings by the people from Motorola on the System V microport. > The AT&T compiler (and, I'm told, the Sun compiler), put the return > value of pointer-valued functions in A0 - NOT in D0. As such, if you don't > declare "malloc" as returning "char *", its caller will expect the return > value to be in D0 and will get whatever junk was there last. The real world is a tough place to live. We decided we could not afford to break all the programs written by lazy programmers so even pointer- valued functions return their result in D0. Also, we once optimized procedure call/return in such a way that it was impossible to implement alloca (allocate memory on the stack of the current procedure, very useful but EXTREMELY implementation dependent). We also had to remove that as a concession to reality. Of course, you've never really had lint problems unless you've had to deal with a word adressed, 24-bit word machine on which int i; char *p; p = (char *)&i; generates more than a simple move instruction! Bill Shannon Sun Microsystems, Inc.