Xref: utzoo comp.lang.c:9299 comp.sys.ibm.pc:14442
Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!quintus!ok
From: ok@quintus.UUCP (Richard A. O'Keefe)
Newsgroups: comp.lang.c,comp.sys.ibm.pc
Subject: Re: cdecl keyword
Message-ID: <875@cresswell.quintus.UUCP>
Date: 14 Apr 88 06:19:42 GMT
References: <1238@wjvax.UUCP> <297@ho7cad.ATT.COM> <1242@wjvax.UUCP> <982@micomvax.UUCP>
Organization: Quintus Computer Systems, Mountain View, CA
Lines: 55

In article <982@micomvax.UUCP>, ray@micomvax.UUCP (Ray Dunn) writes:
[defending Microsoft's 'cdecl'].

If the goal is to provide intercallability between several languages
using different calling conventions, one could do worse than to imitate
Apollo.  Way back when, Apollo provided a Fortran/Pascal system, and made
Fortran and Pascal use the same calling convention.  (Actually, this seems
rather silly to me.  Why pass something by address when you can pass it by
value?)  And then they added C.  So what did they do?  They added a
	std$_call
keyword (I don't remember the exact spelling), so that you only have to
provide this keyword when you are calling something which isn't C.

That's the right way to go.  Anything which requires a different calling
convention couldn't have been part of a "portable" C program, because it
couldn't have been written in C.

Requiring a special keyword just so a language can use its own calling
convention seems, um, odd.

> In article <7606@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn) <gwyn>) writes:
> 
> > Oh, I understand it all right.  But it is a botch.  cdecl acts as a
> > kludge to counteract a more global kludge, rather than solving the
> > inter-language linkage problem directly at the interfaces involved.
> 
Ray Dunn replied
> What do you suggest as an alternative?  To put the onus on the *other*
> languages?

No, Doug Gwyn is right.  The "interfaces involved" are the extern
declarations.  His point is that you should need a special keyword
only when something in language X imports something from language Y,
or exports something to language Y, where X != Y.

For example: file foodef.c defines a function foo() in C,
file bazdef.p defines a function baz() in Pascal, and there are
a C file see.c and a Pascal file pas.p using both functions.  One might
write
	/* in see.c */

	extern		int foo(int, int)
	extern$pascal	int baz(int, int*);

	(* in pas.p *)

	function baz(i: integer; var j: integer): integer;
	    external;

	function foo(i: integer; j: integer): integer;
	    external "C";

You see the point?  You don't need anything outside the standard for
language X to call a subroutine written in language X.  It's only if
you call some other language that the interface has to say which one.