cdecl keyword
Doug Gwyn
gwyn at brl-smoke.ARPA
Thu Apr 14 10:00:24 AEST 1988
In article <982 at micomvax.UUCP> ray at micomvax.UUCP (Ray Dunn) writes:
>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?
Your entire response shows that you missed what I was saying.
Point 1: There need not be a "reference language". However, access to
system-provided objects and functions (e.g. ROM facilities) may
well be designed with a particular language's interface
techniques in mind. That by no means necessitates the concept
of a single system-wide "reference language", however.
Point 2: Each language implementation can provide its own extensions
for interfacing to foreign objects and functions. Thus "__pascal"
would be a reasonable type qualifier to add to the C language in
such an environment.
Point 3: There is not a one-to-one mapping between C and other languages
even at the external interface level, so it is inappropriate to
apply a blanket mapping to an entire C source file. A local
mapping should be used, for example in the external declarations
for foreign externs in a header. I think the blanket mapping
facility was most likely provided so that programmers didn't
have to be aware of what they were doing, which in my experience
is not an approach to be recommended. The other likely reason
would be to speed up the interface, but all that shows is that a
poor choice was made for the C interface design. It need not be
slower than a Pascal interface. People who wish to continue
the discussion on this point are advised to read Bell Labs CSTR
#102 before wasting any more time.
Point 4: My home computer uses a scheme exactly as I have described; it
even has a segmented architecture. Don't accuse me of lack of
experience!
More information about the Comp.lang.c
mailing list