structured assembler (BASIC) [Really: C builtin functions?]

Daniel R. Levy levy at ttrdc.UUCP
Sun Apr 6 08:11:39 AEST 1986


In article <41 at cbmvax.cbmvax.cbm.UUCP>, daveh at cbmvax.UUCP writes:
>C, LISP, Pascal, BASIC, etc., all have standard built-in functions.

C has standard built-in functions????

Gee, that's a new one on me.  EVERY function called from C is an external func-
tion, or at least it was when C began.  This includes things like write(),
read(), printf(), math functions, etc.  There's no such thing as, for example,
a C builtin equivalent to the FORTRAN MAX() or the Basic INPUT which does the
right thing no what the arguments' types are, or where the returned result is
stored.  Of course, C has developed a number of "understood" conventions, like
the omnipresence of the write() and read() functions and their calling conven-
tions but they are not necessarily gospel.  That is, you could compile a
function which takes the place of read() and link it in:

read()
{
	/* This presumes that write() will remain the "standard" version! */
	write(2,"Go fly a kite, I don't feel like reading\n",41);
	return 0;
}

and sure 'nuff it would get called, at least in a Unix environment, every time
that a program tried to read something through read() or through stdio.  (I
tried it.)  Try that with any of the Basic builtins!

I do grant that these conventions like read() and write() have become, through
hallowed usage (mostly in Unix) standard enough that some C compilers can get
away with treating them as builtins without breaking any code except that which
tries to redefine these conventions.  VAX/VMS C, for instance, will treat a
call of read() as a call of something like C$$READ() while not changing a call
of reed() to a call of C$$REED() in analogy.  But that is just cosmetic stuff;
C in essence still behaves as if all functions (following macro expansions)
were external functions, so that (maybe because?) implementations which treat
them that way (e.g., Unix) are still quite valid.
-- 
 -------------------------------    Disclaimer:  The views contained herein are
|       dan levy | yvel nad      |  my own and are not at all those of my em-
|         an engihacker @        |  ployer or the administrator of any computer
| at&t computer systems division |  upon which I may hack.
|        skokie, illinois        |
 --------------------------------   Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa,
						vax135}!ttrdc!levy



More information about the Comp.lang.c mailing list