Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!athena.mit.edu!raeburn
From: raeburn@athena.mit.edu (Ken Raeburn)
Newsgroups: comp.lang.c
Subject: Re: YALF (yet another lint foulup)
Message-ID: <8584@bloom-beacon.MIT.EDU>
Date: 31 Dec 88 21:18:23 GMT
References: <4700030@m.cs.uiuc.edu> <717@auspex.UUCP> <122@mole-end.UUCP> <11245@haddock.ima.isc.com> <9228@smoke.BRL.MIL> <14672@cisunx.UUCP>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: raeburn@athena.mit.edu (Ken Raeburn)
Organization: Masochistic Institute of Technology
Lines: 22

In article <14672@cisunx.UUCP> cmf@unix.cis.pittsburgh.edu (Carl M. Fongheiser) writes:
>In article <9228@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>>What do you mean?  Function value type and whether a function returns
>>are orthogonal.
>Really?  I'm having a good deal of difficulty thinking of any reason why
>one would declare a function which never returns as anything other than
>void.

How about type consistency?  Consider a library package which lets you
supply procedures to run, and expects a structure returned; some
compilers would allocate an invisible first argument telling you where
to put the structure.  If you want your procedure to read its
arguments properly -- even if it's going to do nothing more than print
them out and exit or abort -- its return value must be declared
properly.  (Okay, so I can't name such a package offhand.  The example
is still valid....)

Declaring it as returning some (non-void) type when it is known not to
return is pointless when you've got your choice, but if you have to
mesh with some existing scheme you have to do it anyways.

~~ Ken