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