Xref: utzoo comp.lang.c:8973 comp.sys.ibm.pc:14209
Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!nrl-cmf!mailrus!tut.cis.ohio-state.edu!bloom-beacon!mit-eddie!bbn!rochester!PT.CS.CMU.EDU!cadre!pitt!darth!formtek!ditka!csanta!greg
From: greg@csanta.UUCP (Greg Comeau)
Newsgroups: comp.lang.c,comp.sys.ibm.pc
Subject: Re: cdecl keyword ( re: C Decl ... )
Message-ID: <121@csanta.UUCP>
Date: 5 Apr 88 12:58:55 GMT
References: <1238@wjvax.UUCP> <297@ho7cad.ATT.COM> <1242@wjvax.UUCP> <7595@brl-smoke.ARPA> <2521@bsu-cs.UUCP>
Reply-To: greg@csanta.UUCP (Greg Comeau)
Organization: Comeau Computing, Richmond Hill, NY
Lines: 24

In article <2521@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes:
>In article <7595@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
>writes (about the "cdecl" keyword):
>>Of all the useless additions to C, this one has to take the cake!
>>#define cdecl /*nothing*/
>
>The real usefulness of cdecl comes when one is doing mixed language
>programming.
>

Right.  Another equally valid reason for having cdecl and pascal is
that you may choose to use the pascal modifier on your C routine even
though you do not have any mixed model code.

Why would you want to do this?  Because C builds the stack with the
current arguments every time it goes to do a subsroutine call and it
does not know or care how may arguments there actually is.  Pascal does.
So?  Well this means that the overhead for pascal function calls during
execution is faster because pascal type functions can clean up the
stack when they are finished with a 'ret #bytes' instruction.  With the
"standard" C calling concentions, the caller usually does the cleaning
up with an increment (decrement?) of the sp *after* the call to the function.

Result is: faster & smaller code.  Not too often that you can kill them two
birds with the same stone.