Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!bsu-cs!dhesi From: dhesi@bsu-cs.UUCP (Rahul Dhesi) Newsgroups: comp.std.c Subject: Re: Identifier length? Message-ID: <6161@bsu-cs.UUCP> Date: 16 Mar 89 22:16:22 GMT References: <627@maxim.ERBE.SE> <1989Mar16.171213.21210@utzoo.uucp> Reply-To: dhesi@bsu-cs.UUCP (Rahul Dhesi) Organization: CS Dept, Ball St U, Muncie, Indiana Lines: 33 In article <1989Mar16.171213.21210@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >The Rationale comments: "...strong sentiment >was expressed for making C ``right'' by requiring longer names everywhere... >This is unacceptable since the whole reason for a standard is portability, >and many systems today simply do not provide such a name space..." ^ The 6-character limit is water under the bridge and complaining about it now won't change it, so I won't do that. I do object to the above reasoning, because it implies something incorrect. I've described in the past how simple it is for a C implementation to overcome the 6-character limit of existing linkers without changing the linker. If the programmer can think of a name like "get_time_of_day" and mentally convert it to "gettod" without creating a conflict, surely an implementation of C can do the same. 1. The C compiler generates object files containing long external identifiers when needed. It extends the object file format to accommodate these identifiers. 2. A pre-linker scans all object files. Those that contain no long identifiers are already ready for the system linker. In those that contain long names, it converts the long long names to short ones, and generates code ready for linking with the standard system linker. In each generated short name it adds a special character that never occurs in the name of any library routine. Or it recognizes everything in the ANSI standard libraries and system-specific libraries and avoids generating a conflicting name. -- Rahul Dhesi UUCP: !{iuvax,pur-ee}!bsu-cs!dhesi ARPA: dhesi@bsu-cs.bsu.edu