gurulet aptitude test (and bug)

mcdaniel at uicsrd.csrd.uiuc.edu mcdaniel at uicsrd.csrd.uiuc.edu
Tue Dec 13 16:27:00 AEST 1988


Written  1:45 pm  Dec 12, 1988 by greggy at infmx.UUCP in comp.lang.c:
> In article <44200023 at uicsrd.csrd.uiuc.edu> mcdaniel at uicsrd writes:
>>#4:          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.
>       ^^^^^^^^^^
. . .
> A struct is (traditionally) returned by address
> (or implicitly by copying it to a generally known place).
. . .
> 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
> dereference location zero causes the core dump.

It's a compiler bug.

I compiled and ran this code:
    #include <stdio.h>
    struct zztop { int a; int b; }
    sub1() { struct zztop dummy; printf("in sub1\n"); return dummy; }
    main() { printf("start main\n"); sub1(); printf("end main\n"); exit(0); }

As Greg noted, if "return dummy;" is commented out, this program core
dumps on a SUN 3 under BSD 4.2.  Quoting K&R's 2nd edition (page 225,
section A9.6):
   Flowing off the end of a function is equivalent to a "return" with
   no expression.  In either case, the returned value is undefined.

Note the wording: it says that the VALUE is undefined.  If they had
meant that this is illegal, or that the EFFECT is undefined, I think
K&R would have said so; they are usually very careful in their
terminology in the Appendix.  Therefore, I think that the core dump is
a bug in the SUN compiler, and that the code is legal dpANS C, with a
defined result, whether the "return" is commented out or not.

As a sanity check: functions written before "void" became common
usually have a return type of "int" but do not return a value.  If a
compiler were permitted to make such code illegal, MANY existing
programs would break.  I don't think that the ANSI C committee
intended to permit that.  (There's certainly nothing that says that
"int" functions are treated specially.)

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

--

             Tim, the Bizarre and Oddly-Dressed Enchanter

Center for      |||  Internet, BITNET:  mcdaniel at uicsrd.csrd.uiuc.edu
Supercomputing  |||  UUCP:     {uunet,convex,pur-ee}!uiucuxc!uicsrd!mcdaniel
Research and    |||  ARPANET:  mcdaniel%uicsrd at uxc.cso.uiuc.edu
Development,    |||  CSNET:    mcdaniel%uicsrd at uiuc.csnet
U of Illinois   |||  DECnet:   GARCON::"mcdaniel at uicsrd.csrd.uiuc.edu"



More information about the Comp.lang.c mailing list