Path: utzoo!mnetor!uunet!husc6!im4u!milano!ghostwheel!ned From: ned@ghostwheel.UUCP (Ned Nowotny) Newsgroups: comp.lang.c Subject: Re: A tale of two C's. Message-ID: <154@ghostwheel.UUCP> Date: 20 Apr 88 23:48:07 GMT References: <152@ghostwheel.UUCP> <7691@brl-smoke.ARPA> Reply-To: ned@ghostwheel.aca.mcc.com.UUCP (Ned Nowotny) Organization: MCC Database Program, Austin, Texas Lines: 35 In article <7691@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) writes: >In article <152@ghostwheel.UUCP> ned@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@ghostwheel.aca.mcc.com.UUCP)