home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / lang / fortran / 4672 < prev    next >
Encoding:
Text File  |  1992-12-11  |  2.9 KB  |  61 lines
  1. Newsgroups: comp.lang.fortran
  2. Path: sparky!uunet!cs.utexas.edu!uwm.edu!linac!unixhub!slacvx.slac.stanford.edu!fairfield
  3. From: fairfield@slacvx.slac.stanford.edu
  4. Subject: Re: How common are long variable names?
  5. Message-ID: <1992Dec11.174722.1@slacvx.slac.stanford.edu>
  6. Lines: 49
  7. Sender: news@unixhub.SLAC.Stanford.EDU
  8. Organization: Stanford Linear Accelerator Center
  9. References: <1992Dec11.221459.10841@sol.UVic.CA>
  10. Date: Sat, 12 Dec 1992 01:47:22 GMT
  11.  
  12. In article <1992Dec11.221459.10841@sol.UVic.CA>, klassen@sol.UVic.CA (Melvin Klassen) writes:
  13. > Dr. Kenneth H. Fairfield <fairfield@slacvx.SLAC.Stanford.EDU> writes:
  14. >>    Hurray for IBM's VS Fortran!!!  31-character identifiers allowed,
  15. >>but if you should be so bold as to use an identifier > 7 characters long
  16. >>for a global symbol (i.e., SUBROUTINE, FUNCTION, ENTRY, BLOCK DATA, or
  17. >>COMMON block name), it takes the first 4 characters and concatenates
  18. >>them with the last 3 characters of the (long) identifier to generate the
  19. >>external name.  Think about the following (generic) utilities:
  20. >>
  21. >>        SUBROUTINE UTL_GET_DATA
  22. >>        SUBROUTINE UTL_PUT_DATA
  23. >>        SUBROUTINE UTL_CLEAR_DATA
  24. > 
  25. > If you CALL more than one of these routines from a single program-unit,
  26. > the compiler reports the error-message:
  27. >    ILX1454I  Two or more external symbols are not unique.
  28. >              Check the "external symbol report".
  29. > 
  30. > The ICA (InterCompilation Analyzer) reports the diagnostic:
  31. >    ILX0067I  Conflicting name usage -- the name, UTL_ATA has been used
  32. >              as the name of a subroutine in UTL_ATA (compilation 2) and
  33. >              as the name of a subroutine in UTL_ATA (compilation 3).
  34. > 
  35. > The compiler is doing as best as it can!
  36. > It's the IBM linker/loader which is the bottle-neck,
  37. > due to the restriction to 8-character external names,
  38. > so don't blame the IBM FORTRAN-development group
  39. > for a problem which they have no authority to fix!
  40.  
  41.     Well, I _didn't_ "name names", you did ;-)  I didn't say "the IBM 
  42. FORTRAN-development group" stinks because of this kluge, I said, in
  43. effect, "look what happens" if you use long names with VS FORTRAN.  And
  44. it's not just the linker/loader people, it goes all the way down to the
  45. file system in some cases...
  46.  
  47.     My posting was in sympathy to J. Giles' (?) remark about compilers
  48. which _accept_ long names but, in essence, don't _support_ them.  Yes, at
  49. least IBM is flagging the possible conflict...  My personal opinion is
  50. that it would be better for them to say, "We support long variable names,
  51. but externals still need to be limited to 7 characters".  That would be 
  52. clear; the other lays a trap for the unwary.
  53.  
  54.         -Ken
  55. -- 
  56.  Dr. Kenneth H. Fairfield    |  Internet: Fairfield@Slac.Stanford.Edu
  57.  SLAC, P.O.Box 4349, MS 98   |  DECnet:   45537::FAIRFIELD (45537=SLACVX)
  58.  Stanford, CA   94309        |  BITNET    Fairfield@Slacvx
  59.  ----------------------------------------------------------------------------
  60.  These opinions are mine, not SLAC's, Stanford's, nor the DOE's...
  61.