cdecl keyword ( re: C Decl ... )

[Barnacle Wes]

In article <7595 at brl-smoke.ARPA> gwyn at 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*/

In article <2521 at bsu-cs.UUCP> dhesi at bsu-cs.UUCP (Rahul Dhesi) writes:
> The real usefulness of cdecl comes when one is doing mixed language
> programming.

In article <121 at csanta.UUCP>, greg at csanta.UUCP (Greg Comeau) writes:
% [...] 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.

So why should we force these MS-DOSisms on the rest of the C-speaking
world?  This is yet another kludge around the Intel iAPX?86
architecture (or lack thereof :-), just like "near" and "far".  Tell
me, what does "near" mean on a 68000 system?  I can call C routines
from the Unix fortran compiler WITHOUT declaring the C routine to be
of "fortran calling sequence."  Let's not put these kludges in a C
language standard.  If your programming environment needs them, let
them be (non-portable) extensions to the standard needed to support
your (non-) operating system!
-- 
    /\              -  "Against Stupidity,  -    {backbones}!
   /\/\  .    /\    -  The Gods Themselves  -  utah-cs!utah-gr!
  /    \/ \/\/  \   -   Contend in Vain."   -  uplherc!sp7040!
 / U i n T e c h \  -       Schiller        -     obie!wes