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.