A tale of two C's.

[Ned Nowotny]

In article <7691 at brl-smoke.ARPA> gwyn at brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>In article <152 at ghostwheel.UUCP> ned at ghostwheel.aca.mcc.com.UUCP (Ned Nowotny) writes:
>>Now, however, X3J11, in the interest of runaway optimization, has exploded
>>the name space of the language by reserving a whole host of function, macro,
>>and data names.
>
>I don't believe you could have studied the proposed standard before posting
>this nonsense.  How would "exploding the name space" possible serve the
>interest of "runaway optimization"?

Of course, the newly "reserved" function, macro, and data names are reserved
primarily to support portability.  However, there have been more then a few
comments in this newsgroup supporting the idea that "optimizing" compilers
should recognize standard functions like strcpy() and replace their invocation
with "semantically equivalent" in-line code.  Treating strcpy(), or any other
standard library function, in this manner effectively adds these functions to
the implementation's set of keywords.

While standardizing the library functions and header files is a positive boon
to portability, implementors should not take X3J11's reservation of these
element names as a license to roll the handling of functions or macros which
match the standard names into the compiler.  When portability is not an issue,
a programmer should be free to use his or her own implementation of a standard
library function.

Frankly, an "optimizing" link editor which could inline short functions based
on metrics provided by the programmer would be preferable.  Such a link editor
would also be less likely to link in "dead" code and could possibly obviate
the need for prototypes if sufficient information was provided in the symbol
tables generated by the compiler.  (At least, we might be able to get away
from the maintenance problem caused by effectively requiring multiple
declarations of the same function.)
-- 

Ned Nowotny (ned at ghostwheel.aca.mcc.com.UUCP)