Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!cmcl2!harvard!uwvax!topaz!bentley!kwh
From: kwh@bentley.UUCP (KW Heuer)
Newsgroups: net.lang.c
Subject: C builtin functions?
Message-ID: <709@bentley.UUCP>
Date: Fri, 11-Apr-86 15:37:06 EST
Article-I.D.: bentley.709
Posted: Fri Apr 11 15:37:06 1986
Date-Received: Sun, 13-Apr-86 08:11:49 EST
References: <1224@ulysses.UUCP>
Organization: AT&T Bell Laboratories, Liberty Corner
Lines: 30

In article <1224@ulysses.UUCP> ulysses!jss (Jerry Schwarz) writes:
>>Indeed, X3J11 has decreed that there must be an actual
>>extern definition of each required function....
>
>There may have been a recent change of heart, but the Feb 86 draft
>stated (D.1.2):
>
>        All external identifiers declared in any of the  headers
>        [enumerated in the standard] are reserved, whether or not
>        the associated header is included. ...

This is not necessarily a contradiction; even if strcpy *IS* compiled
into a single instruction, there must *ALSO* be a copy in the library
so you can take its address.

I'm all for optimization, but having the functions built-in disturbs
me a little.  There are applications that have to run stand-alone;
e.g. the UNIX* kernel (which has some functions of its own with names
identical to those in libc).  Will these have to be renamed to conform
to the standard?  Perhaps there should be a compiler option to inhibit
expansion of builtins?

Actually, it seems to me that the correct way to handle it is with an
optimizing *loader*.  When the loader detects a call to strcpy, and
sees that strcpy in libc is small, it could do the inline expansion.
Yes, I realize that this requires more information (and smarts) than
today's loader has available, but just wait...

Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint
*UNIX is a trademark of AT&T Bell Laboratories