Path: utzoo!attcan!uunet!ncrlnk!ncr-sd!hp-sdd!hplabs!pyramid!infmx!greggy
From: greggy@infmx.UUCP (greg yachuk)
Newsgroups: comp.lang.c
Subject: Re: gurulet aptitude test (and bug)
Message-ID: <682@infmx.UUCP>
Date: 12 Dec 88 19:45:46 GMT
References: <228@celerity.UUCP> <44200023@uicsrd.csrd.uiuc.edu>
Reply-To: greggy@infmx.UUCP (greg yachuk)
Organization: Informix, Menlo Park, Ca. U.S.A.
Lines: 26

In article <44200023@uicsrd.csrd.uiuc.edu> mcdaniel@uicsrd.csrd.uiuc.edu writes:
>II    Line 4: the declaration of "struct zztop" was probably meant to
>      have a ";" after the closing "}".  Without it, sub1()'s return
>      type is "struct zztop":
>            struct zztop {int a; int b;} sub1() {...}
>      With a ";", sub1()'s return type is an int.  This point is
>      irrelevant, really, since sub1's return value is always ignored.
       ^^^^^^^^^^
Actually, this is THE bug.  A struct is (traditionally) returned by address
(or implicitly by copying it to a generally known place).  It is then the
responsibility of the caller to not only remove the parameters from the
stack, but also to copy the returned value from where-ever to some local
place (variable or temp-location).  On a SUN-3, it appears to return the
address.  With this example code, a zero just *happens* to be the returned
value, since sub1() does not explicitly return a value.  Attempting to
dereferece location zero causes the core dump.

>             Tim, the Bizarre and Oddly-Dressed Enchanter

	-greg

Greg Yachuk	Informix Software Inc., Menlo Park, CA	(415) 322-4100
{uunet,pyramid}!infmx!greggy	why yes, I DID choose that login myself

"May I remind you that here at Atherton, Pembroke & Wills we do *not*
take fashion risks?"		-- Leo Cullum