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

Daniel R. Levy levy at ttrdc.UUCP
Wed Apr 16 15:26:31 AEST 1986


Looks like I've started a minor ruckus here in net.lang[.c].

The consensus (other than all the quibbling about sizeof) seems to be that
C may, but needn't, implement the "standard" functions as wholly external
(and thus user-replaceable) in today's world.  My original comments to the
effect that all C functions are external reflect my impression of
the K and R approach to the matter (The comment is very near the front
of the book, and specifically makes a point about the I/O functions.)

I think that inline expansion would make lots of sense for cases
like printf() (which as an external function call must interpret its
format at run time when used with a fixed format string).  In this case,
it could be treated much as Fortran treats formatted I/O statements,
parsing the formats at compile time.  (Or at least highly efficient For-
trans, such as VMS's, do this; a side benefit is that format errors are
detected at compile time, catching things like using an integer format
to print out a double precision variable, etc.  In the case of C, 
this kind of treatment could catch this kind of error and others which 
are peculiar to printf and its kin, such as too few or too many arguments
after the format.)

Someone commented (either on the net or to me) that hosted C language
implementations were expected to have an external set of the "standard"
functions on hand even if they were treated differently when invoked
inline.  This kind of makes sense, since C lets a user pass a pointer
to a function to another function which is allowed to invoke it by
pointer, and it might be desireable to use a "standard" function in
that way, e.g., passing strcmp() as a comparison routine to a general
purpose searching or sorting routine a la qsort().  Are there other
reasons?  (Far be it from me to fuel further debate :-) ).
-- 
 -------------------------------    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