It heard the word \"power\" and responded, just like we do!

[Doug Gwyn]

In article <11440 at brl-adm.ARPA> lamonts at 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.