Xref: utzoo comp.lang.c:8766 comp.sys.ibm.pc:13951
Path: utzoo!utgpu!water!watmath!clyde!rutgers!cmcl2!nrl-cmf!mailrus!umix!uunet!portal!cup.portal.com!Devin_E_Ben-Hur
From: Devin_E_Ben-Hur@cup.portal.com
Newsgroups: comp.lang.c,comp.sys.ibm.pc
Subject: Re: cdecl keyword
Message-ID: <4259@cup.portal.com>
Date: 2 Apr 88 03:48:51 GMT
References: <1238@wjvax.UUCP> <297@ho7cad.ATT.COM> <1242@wjvax.UUCP> <7595@brl-smoke.ARPA>
Organization: The Portal System (TM)
Lines: 39
XPortal-User-Id: 1.1001.3645

Doug Gwyn writes:
> In article <1242@wjvax.UUCP> miker@wjvax.UUCP (Michael Ryan) writes:
> >	char cdecl steve( int f , char g)
> > is a C language routine that pushes arguments according to C conventions,
> > g then f, with appropriate sizes, etc. 
>
> Of all the useless additions to C, this one has to take the cake!
> #define cdecl /*nothing*/
 
  Actually, there is a reason for both MSC and TC to have introduced the
cdecl modifier.  Both these compilers support multi-language environments
using modifier keywords such as "pascal" & "fortran" to specify the
linkage and naming conventions.  They also both support compile switches
which allow C functions to be compiled using the foreign language
conventions as the default. This is convenient if you intend to have
your C functions used as library routines for the foreign language.  It
also is nice because it produces faster and more compact code (the
callee pops args using RET <n> instead of the caller having to restore
the stack frame after every function call).
 
  A problem arrises when using standard library functions while having
the foreign language switch on.  Unless the user has bought and
re-compiled the library source code, the linkage conventions will be
wrong!  This is the justification for cdecl.  All the prototypes for
library functions are declared as cdecl functions in the .H files
supplied by the vendor to allow the user to take advantage of the
better code quality without having to shell out the $$$ for the library
source.
 
  Please don't be so quick to flame extensions that you don't understand.
The MS-DOS/80x86 environment is not pretty.  Some of us have to sweat blood
to get high quality applications to run fast and fit in a severely
constrained, somewhat-crippled architecture.  Borland's & uSoft's
extensions for supporting the 80x86 environment (near,far,huge,cdecl,
pascal,fortran,interrupt,asm,psuedo-registers,etc.) are a blessing
to those of us without the luxury of large virtual linear address spaces
and real operating systems.

ucbvax!sun!portal!devin.e.ben-hur%cupertino.pcc