Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ucbvax!husc6!cca!g-rh
From: g-rh@cca.CCA.COM (Richard Harter)
Newsgroups: comp.lang.c
Subject: Re: functions defaulting to int
Summary: Yes, it was a design error
Message-ID: <23327@cca.CCA.COM>
Date: 17 Jan 88 02:28:00 GMT
References: <528@gtx.com> <7111@brl-smoke.ARPA>
Reply-To: g-rh@CCA.CCA.COM.UUCP (Richard Harter)
Organization: Computer Corp. of America, Cambridge, MA
Lines: 34

In article <7111@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>
>>In my opinion, one of the main design flaws in  C is the rule that
>>makes procedures int by default.
>
>From today's point of view, yes, but before the advent of "void"
>it was quite convenient.  Of course it can't be changed now, due
>to the amount of correct existing code that would be invalidated.
>
>By the way, failure to properly declare malloc() is a common bug.
>It seems that since everyone has to cast its return result to the
>proper pointer type, they fail to observe that letting it default
>to int before the cast is simply wrong.

From yesterday's viewpoint also.  We (SMDS) don't use void or hardly
anything else that is not in K&R, for strictly pragmatic reasons of
portability.  However, even in the context of K&R, integers defaults
were a design error.  One could have just as well had the rule that
all items had to have a type declaration.  The 'integer default'
rule is the sort of thing that leads to accidental bugs, and code
that isn't portable.

Incidentally, I am inclined to believe that the decision to have only
functions (which, in principle return a value) and not also have
procedures (subroutines) which do not return a value was a design
error.  The idea that procedures are a special case of functions is
elegant and all that, but the introduction of 'void' is a tacit
admission that this particular conceptual unification was not
desirable.
-- 

In the fields of Hell where the grass grows high
Are the graves of dreams allowed to die.
	Richard Harter, SMDS  Inc.