Path: utzoo!attcan!uunet!husc6!cmcl2!nrl-cmf!ames!ncar!noao!asuvax!stjhmc!p6.f18.n114.z1.fidonet.org!will.summers
From: will.summers@p6.f18.n114.z1.fidonet.org (will summers)
Newsgroups: comp.lang.c
Subject: Re: "Numerical Recipes in C" is nonport
Message-ID: <660.2333D246@stjhmc.fidonet.org>
Date: 17 Sep 88 22:56:43 GMT
Sender: ufgate@stjhmc.fidonet.org (newsout1.24)
Organization: FidoNet node 1:114/18.6 - Iasd Eng Bbs, Phoenix Az
Lines: 40


 In article <3981@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes:
 > In article <8507@smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) )
 > writes:
 > >C extern names are not necessarily unique beyond 6 characters,...
 > I think Doug Gwyn exaggerates in saying "many" and "of necessity".
 
I hate this restriction (big deal! **everybody hates this**, even the 
committee!)
 
So what to do?
 
Liberally paraphrasing the Rationale:
 dpANS work-around 2:
   Use defines:
       #define real_long_name   a_xyz_real_long_name
       #define real_long_name2  a_rwt_real_long_name2
 
 dpANS work-around 3:
   Use longer names and kiss portability to short-extern environments goodby.
 
What to do?
 
Well dpANS *permits* the implementor to honor as much significance as he 
wishes. In practice an implementor affected by market forces will honor as 
many characters as his environment permits.
 
So I choose (3), and will add #defines al'a (2) if I ever need to port to a 
short-extern environment.
 
I think so many programmers in longer-extern environments will do the same 
that those importing to short-extern environments will encounter the problem 
often enough to develop tools to generate the #defines automatically.
 
    \/\/ill


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