Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 exptools 1/6/84; site ihnp3.UUCP Path: utzoo!watmath!clyde!burl!mgnetp!ihnp4!ihnp3!dhp From: dhp@ihnp3.UUCP (Douglas H. Price) Newsgroups: net.unix-wizards Subject: Re: Bug in System V C compiler Message-ID: <114@ihnp3.UUCP> Date: Mon, 13-Aug-84 17:56:47 EDT Article-I.D.: ihnp3.114 Posted: Mon Aug 13 17:56:47 1984 Date-Received: Tue, 14-Aug-84 02:14:24 EDT Organization: AT&T Bell Labs, Naperville, IL Lines: 28 I've watched the assorted flaming about the supposed bug in the System V C compiler with some amusement. I suggest, however, that it more appropriately belongs in either net.lang.c or better yet net.flame, since this is a case of what you want it to do rather than what it currently does. It clearly states on page 179 of K & R (reference section 2.2) that in the K & R definition of C that no more than the first eight characters are significant, with the possibility that various local assemblers and loaders might put additional restrictions on externals. In fact, it explicitly states that only seven chars are significant on a PDP-11, the parent compiler to the VAX. So, what you are really arguing about is not a bug in the compiler, but rather an arbitrary limitation of the assembler and loader on the machine. As a note to you who are implementing what you intend to be fully portable code; you have even tighter restrictions. The only way you can have moderate assurance that the program will link on non-UNIX systems is if you limit your externals to six characters, upper case only. It looks ugly, but it works. It just so happens that longer externs will be supported in System V.2 so this whole argument will soon be moot anyway. -- Douglas H. Price Analysts International Corp. @ AT&T Bell Laboratories ..!ihnp4!ihnp3!dhp