Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!panda!husc6!harvard!caip!lll-crg!lll-lcc!pyramid!gould9!ncr-sd!greg From: greg@ncr-sd.UUCP (Greg Noel) Newsgroups: net.lang.c Subject: Re: C Builtin Functions Message-ID: <479@ncr-sd.UUCP> Date: Wed, 7-May-86 23:46:03 EDT Article-I.D.: ncr-sd.479 Posted: Wed May 7 23:46:03 1986 Date-Received: Fri, 9-May-86 10:42:21 EDT References: <1700010@umn-cs.UUCP> <788@bentley.UUCP> Reply-To: greg@ncr-sd.UUCP (Greg Noel) Organization: NCR Corporation, San Diego Lines: 46 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@bentley.UUCP> kwh@bentley.UUCP (KW Heuer) writes: >In article <1700010@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 " (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@ncr-sd.UUCP or Greg@nosc.ARPA