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