"Numerical Recipes in C" is nonport

will summers will.summers at p6.f18.n114.z1.fidonet.org
Wed Sep 21 16:44:54 AEST 1988


(Re: dpANS guarentee of only 6 monocase characters of external name 
     significance)

In article <10295 at bellcore.bellcore.com> sjs at jcricket.ctt.bellcore.com 
(Stan Switzer) writes:
 > Two is a couple.  A few is at least three (in my book).  I guess
 > *many* will have to be at least four.  
 
Ah... the way I heard it was two's company, three's a crowd, four's a
fist fight and five's a riot.  Guess we need six.  :-)


 > "How many C implemenations are constrained by 6 character monocase
 > linkers and how badly are they constrained?"

 >   1) GECOS / GCOS / GCOS 8
 >      for the GE 600 / Honeywell 6000 / DPS 8 series
 > 
 > Being essentially quantitative, the first part of this controversy is
 > easier to resolve than the second, but as of my last experience w/
 > GCOS (1982), I don't feel I'd have lost very much in abandoning the
 > standard linker in favor of a "C" linker.

I believe the committee's concern was over those installations where
security prevented all but "secure" programs from generating an 
executable module.  Does GCOS qualify?  I -think- the waterloo C compiler
for GCOS (single segment) recoginzes 100 case-siginificant characters 
in external names.

I am a supporter of dpANS, but have trouble understanding this decision.
Even if the implementor could not generate his own linker, it would 
seem that he could implement a pre-link pass that mapped longer 
identifiers in the .o files (or whatever).  Non-dpANS .LIB  files 
would need an associated mapping file.  Maybe I just don't understand
but it seems a small price for the rest of the world to enhjoy 32-bit
externs.                                 

I forsee this limitation as one of the most widely ignored, even by 
many programmers that are otherwise careful about portability 
considerations.

    \/\/ill 

    


--  
St. Joseph's Hospital/Medical Center - Usenet <=> FidoNet Gateway
Uucp: ...{gatech,ames,rutgers}!ncar!noao!asuvax!stjhmc!18.6!will.summers



More information about the Comp.lang.c mailing list