Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!mailrus!tut.cis.ohio-state.edu!ukma!rutgers!cmcl2!adm!smoke!gwyn From: gwyn@smoke.BRL.MIL (Doug Gwyn ) Newsgroups: comp.std.c Subject: Re: External Linkage in dpANS C Message-ID: <9274@smoke.BRL.MIL> Date: 4 Jan 89 08:09:19 GMT References: <1339@vsi1.COM> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 64 In article <1339@vsi1.COM> bitbug@vicom.COM (James Buster) writes: >I saw mentioned in passing in one of these newsgroups (comp.std.c, comp.lang.c) >that a variable with external linkage in dpANS C is resolved with 6 significant >characters and no case sensitivity. I have some questions regarding this: >1. Is this true? Only for a few implementations. Most will do considerably better. >2. Is six significant monocase characters the *minimal implementation*, > or *required*? Valid C external object/function identifiers that differ in their first 6 characters other than in case must be treated as distinct. >3. If required, why should a case sensitive language like C > use a case insensitive linker? Compiler implementors don't always have control over the linker. Many older linkers provided only what Fortran required. Even the PDP-11 UNIX linker had short externs (7 C source characters), although no case folding. >4. If required, why should I damage my flexnames linker? Flexnames linkers are permitted. >5. If required, why should anybody want to use such a brain damaged > implementation of C? Would you rather use Fortran or Cobol? >5. If required, how can only 6 significant characters be portable? Portable programs should not rely on more than that. >6. If required, why should companies with ancient linker technology > force me to use such ancient technology, or why can't they use 80s > linker technology? It's not necessarily the compiler vendors who are responsible for the restrictions. Some old operating systems are too hard (read: traumatic) to change, and until there are enough "modern" users of those systems, the operating system vendor cannot justify making the effort. To do so simply to advertise conformance to the C standard would not be considered good enough reason, and requiring more in the standard would simply result in fewer conforming implementations -- not better linkers. That would be a disservice to C programmers. >7. I presume I don't have to explain the number of programs > that would break because of this behavior (in particular, > the external identifiers _printw and _printf conflict). > Also, creating a function Write to interface to the system > write function (along with some extra stuff) is relatively > common practice. No doubt about it, some programmers have been blissfully unaware of the realities of portable programming. There is no change in this area due to the proposed C standard. >8. In general, aaaarrrrggghhh! Complain to your linker vendor if you run into this problem. I wish you luck.