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