C builtin functions

[KW Heuer]

In article <836 at ttrdc.UUCP> ttrdc!levy (Daniel R. Levy) writes:
>I think that inline expansion would make lots of sense for cases like
>printf() [which could] parse the formats at compile time [and catch
>mismatched formats and variables].

The smart versions of lint can already detect such format mismatches in
printf() and scanf().  This is actually more powerful than having it done
by the C compiler, because cc would only recognize the builtin functions
(i.e.  those in libc) while lint can be told that any given function is
"printf-like".  Of course it's a kludge either way, and won't help with
other functions based on the same principle, such as tparm() in libcurses.

The only advantage I can see in a builtin printf() is that it might be
possible to optimize  printf("%d\n",n);  into  d_printf(n); putchar('\n');
and avoid loading the entire printf library (the "%g" functions, etc.)

>Someone commented that implementations were expected to have an external
>set of the "standard" functions on hand [for pointer passing], e.g. passing
>strcmp() as a comparison routine to qsort().  Are there other reasons?

For reasons I won't elaborate here (other than to mention orthogonality and
the Spirit of Unix), I'm opposed to the idea of builtin functions.  I might
support the idea of additional operators for sufficiently primitive
operations.  (Unary "|" for abs()?  Binary "><" for min(), "<>" for max()?
Now that would drive the pascal/basic users batty! :-)  And we'd get "><="
and "<>=" operators for free.)  I don't want C to get overblown like ksh
(where "kill" is a builtin!).

Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint
Why won't people fix the Newsgroups and Subject lines when the topic changes?