Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site kovacs.UUCP Path: utzoo!linus!philabs!cmcl2!seismo!hao!hplabs!sdcrdcf!randvax!kovacs!day From: day@kovacs.UUCP (David Yost) Newsgroups: net.lang.c Subject: no excuse for short identifiers in the standard Message-ID: <193@kovacs.UUCP> Date: Tue, 9-Oct-84 13:45:02 EDT Article-I.D.: kovacs.193 Posted: Tue Oct 9 13:45:02 1984 Date-Received: Sat, 13-Oct-84 01:15:10 EDT Organization: Robt Abel & Assoc, Hollywood Lines: 49 There have been many, many wonderful arguments for standard long global identifiers on net.lang.c, more than anything I could ever think of. The only important argument against long externals has been that on some systems it is impossible to build a compatible implementation. Nonsense. To C implementors on those unfortunate systems that have object module formats with monocase identifiers or identifiers limited to 2, 5, 6, 8, or whatever, follow these simple steps: 1. Design a new object module format that conforms to the C standard. Implement your C compiler to output this format (preferably after going through an assembler, which you should also provide). 2. If it is impossible to design the C object format so that it can be executed by the operating system, then provide a translator from C object format to executable format or provide a linker option for making an executable. Be sure you provide a way to output the executable with a complete symbol table, so a reasonable debugger can be implemented. 3. If there is a need to link in modules produced by some other language, such as fortran or macro, then provide an object translator from that format to your C object format. If the identifiers in that language are monocase, then map them to lower case in the C format. This conversion program should provide for an optional lookup table mapping old names to new names. If that's too much work, then please don't implement a C compiler at all. Since many new linkers and assemblers are going to have to be built, I suggest that an ANSI C assembler/linker standards committee should be formed to try to keep this part of the C compiler environment standard. One of the important issues here is that provision should be made for symbol table information to support source-level debuggers. And please, let's not standardize on the unix linker. It's too simple-minded. --dave yost