Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!iuvax!bsu-cs!dhesi From: dhesi@bsu-cs.UUCP (Rahul Dhesi) Newsgroups: comp.lang.c Subject: Re: "Numerical Recipes in C" is nonport Message-ID: <4111@bsu-cs.UUCP> Date: 25 Sep 88 21:22:03 GMT References: <5162@hoptoad.uucp> <225800072@uxe.cso.uiuc.edu> <4071@bsu-cs.UUCP> <1988Sep24.212346.26591@utzoo.uucp> Reply-To: dhesi@bsu-cs.UUCP (Rahul Dhesi) Organization: CS Dept, Ball St U, Muncie, Indiana Lines: 40 I wrote: A custom post-processor takes these object files, scans for all long identifiers, shortens them to unique 6-char names, and produces as its output system-format object files ready for the standard linker. In article <1988Sep24.212346.26591@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >Right, so we build it into the output phase of the compiler, since it >doesn't have to do any linking. Now we have a compiler whose output >contains only 6-character names. How is this an improvement on simply >doing that from the beginning? *If* existence of the post-processor could be assumed on the handful of systems with old linkers, using the post-processor would be better than using 6-char externs in the source to begin with, because: It would let people on systems with modern linkers use long externs in their C programs, knowing that their code would still be portable to systems with old 6-char linkers. Existence of the post-processor could be assumed *if* ANSI were to mandate long externs in all conforming compilers and recommend such post-processing to implementors stuck with an old linker. By the way, you can't really build the post-processor into the output phase of the compiler. It has to have access to all user files that will be linked so it can look for conflicting symbols and disambiguate them. The compiler itself might be used in a makefile to compile only one file at a time, so it won't know about all identifiers that conflict when truncated to 6 characters. (The above discussion is largely moot, because the 6-char limit on portable programs is here to stay for the next few years. But it's worth seeing that this limit was not necessary, and that the common arguments in its favor are not valid. This is *not* meant to be a flame.) -- Rahul Dhesi UUCP:!{iuvax,pur-ee,uunet}!bsu-cs!dhesi