Xref: utzoo comp.lang.c:9264 comp.sys.ibm.pc:14409
Path: utzoo!mnetor!uunet!husc6!bloom-beacon!gatech!mcnc!decvax!decwrl!pyramid!prls!philabs!micomvax!ray
From: ray@micomvax.UUCP (Ray Dunn)
Newsgroups: comp.lang.c,comp.sys.ibm.pc
Subject: Re: cdecl keyword
Message-ID: <982@micomvax.UUCP>
Date: 13 Apr 88 00:12:59 GMT
References: <1238@wjvax.UUCP> <297@ho7cad.ATT.COM> <1242@wjvax.UUCP> <7595@brl-smoke.ARPA> <4259@cup.portal.com> <7606@brl-smoke.ARPA>
Reply-To: ray@micomvax.UUCP (Ray Dunn)
Organization: Philips Electronics Ltd. (TDS - Montreal) St. Laurent QC, Canada
Lines: 77
Summary: There are more things in heaven and earth......


In article <4259@cup.portal.com> Devin_E_Ben-Hur@cup.portal.com writes:

> Please [Doug] don't be so quick to flame extensions that you don't
> understand.

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
> kuldge to counteract a more global kludge, rather than solving the
> inter-language linkage problem directly at the interfaces involved.

What do you suggest as an alternative?  To put the onus on the *other*
languages?  Sure, that is possible, but who says 'C' has to be the reference
language?  The Microsoft approach is *not* a kludge, in fact within the
MSDos environment the inter-language abilities are clean, useful, and fairly
consistent. [Good grief, I'm actually defending Microsoft.....]

>....The
>80x86 world has no excuse for the mess it has gotten itself into.

We all have our favourite rankings of machine architectures. They are
usually in reverse order than the number of units sold (:-(.

It is immaterial whether one likes or dislikes the architecture or "mess" of
the 80x86 world or whatever it has "gotten itself into".  It exists.  It has
to be lived with - although, in fact, when programming in other than
assembler it *rarely* has to be given a second thought!

Let us not hide our heads in the C-sand.

The tools have to be provided.  cdecl is such a tool.  In fact, together
with its pascal, fortran and associated keywords and the other
inter-language features, it is part of a consistant and elegant solution to
something that isn't even addressed in other architectures and operating
systems (and I wont even name any n*mes).

The full capabilities and libraries of various languages are open for mutual
use by all.  If you have been following the various C/Fortran/etc wars going
on in comp.whatever you might appreciate why this might be important.

If I could be so bold, from the documentary evidence of the exchange on this
subject, at the time of Doug's initial one line sarcastic dismissal of cdecl
he either did *NOT* understand its full ramifications, or he still does not
understand its usefulness or the power hybrid language programming can
provide.

> The very fact that you have to declare that the C source code is
> intended to follow C rules and not some other rules is ludicrous.

Yup, he doesn't understand.

Sure, on the fa'C'e of it, to have a declaration in 'C' saying "this is a C
declaration" is daft!

In a wider context than the narrow one of 'C', however, it indeed makes
sense.

If the "main" language is Pascal (or Fortran), then why not put the onus on
the C parts to define that they should be Pascal (or Fortran) like.

The inter-language interfaces *are* handled at the interfaces involved - the
external variable and procedure interfaces!

Now this can be specified locally at individual interfaces, or *globally*,
not only as a shorthand, but also if you like, as lip service to the fact
that Pascal is the reference language.

This Pascalitis can be overridden in specific instances by a cdecl for the
various good reasons alluded to in various other informative postings.

(I also happen to very much like the simultaneous code and space
optimization of procedure calls available when the caller does not have to
worry about parameter cleanup - something I've always thought of as a minor
irritant in 'C').

Ray Dunn.  ..{philabs,mnetor}!micomvax!ray