C Builtin Functions

Greg Noel greg at ncr-sd.UUCP
Thu May 8 13:46:03 AEST 1986


I'm surprised that with all this discussion on built-ins, nobody has pointed
out how the C standard specifies that it should work.  My copy of the standard
is pretty old and has been stolen, so perhaps it was removed in a later
specification?

In article <788 at bentley.UUCP> kwh at bentley.UUCP (KW Heuer) writes:
>In article <1700010 at umn-cs.UUCP> umn-cs!herndon writes:
>>I feel compelled to go on record as being VERY MUCH AGAINST having reserved
>>procedure names in C. ......
>>One of the (in my opinion) great strengths of the C language is that it
>>does not have 'built-in' functions.
>
>After rethinking this question, I've decided that it *does*.  However, the
>builtins are all punctuation ("%"), whereas the library functions are all
>alphanumeric ("abs").
>	.......
>Here's my opinion.  Using punctuation for builtins (and alphanumerics for
>library functions) is a nice way to keep them straight; let's keep it that
>way.  If certain functions are so trivial that it's worthwhile for them to
>be expanded inline (are there any besides abs(), min(), and max()?), then
>they should have non-alphanumeric spellings; i.e. they should be operators.

No, what the standard does (did?) is reserve all names that begin with one
or two underscores.  There is some difference in meaning between the two,
but it's not important here.  Pick one of these names, say, __OPEN, and
build it in to the compiler (i.e., it produces in-line code).  Then you
simply act as if there were an implicit "#define open __OPEN" at the head
of each program so that under normal circumstances the built-in version
is used.  If you want to provide your own "open" routine, all you have to
do is have an "#undef open" in your program and the external semantics we
all know and love are used instead.

This seems to solve both of your needs without turning C into APL.  If this
technique is still in the standard, this debate is moot.  If it's not, then
I, for one, would like to know why it was removed.

Aside:  I think that all of the machine-specific names should be in a file
somewhere and the preprocessor should implicitly read it, as if there were
a "#include <standard.h>" (or equivalent) as the first line of every
program.  This would have the #defines for the machine, architecture, OS,
and whatever else it takes to describe the environment.  The header for
the standalone environment simply wouldn't have the #defines for whichever
syscalls are built-in (like __OPEN above) but might have #defines for, say,
abs, l3tol/lto3l, or memcpy if it made sense.
-- 
-- Greg Noel, NCR Rancho Bernardo    Greg at ncr-sd.UUCP or Greg at nosc.ARPA



More information about the Comp.lang.c mailing list