"Numerical Recipes in C" is nonport

[Rahul Dhesi]

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 at utzoo.uucp> henry at 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:  <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi