Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!amdcad!ames!nrl-cmf!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: It heard the word \"power\" and responded, just like we do!
Message-ID: <7174@brl-smoke.ARPA>
Date: 24 Jan 88 23:01:28 GMT
References: <11440@brl-adm.ARPA>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 35

In article <11440@brl-adm.ARPA> lamonts@Sds.Sdsc.EDU (Steve Lamont) writes:
>... (in fact, there are no 
>INTRINSIC functions, in the FORTRAN sense at all in the C language, ...

ANSI C will permit most standard library functions to be implemented
as intrinsics, with the additional feature that there is a way to
guarantee that an actual library function is used when necessary.

	/* <string.h> extract: */
	void memcpy( char *d, const char *s, int n );
	#define memcpy( d, s, n )	__BLOCK_MOVE( n, s, d )
					/* above is a compiler intrinsic */
	/* ... */
	/* application code extract: */
		memcpy( a, b, i );	/* expanded in-line by compiler */
	/* ... */
	#undef memcpy
		fill( p, sizeof *p, memcpy );	/* pass function pointer */

>For example, named COMMON seems to me 
>to be a better way of handling external variables than simply hanging them out
>in space.  The only disadvantage that I seen in COMMON is that names of things
>in COMMON can be different between subprogram units, making the code harder
>to understand.  It is, however, a neat (in both senses of the word) way of
>logically grouping externals.

The possibility of disagreement in the COMMON variables among FORTRAN
subprograms is a frequent cause of bugs.

If you want to do something analogous in C, you can use an extern
structure to package the data under a single visible name.

Actually, inter-module communication via global data is contrary to
well-established structured design principles.  It should be used
sparingly or not at all.