home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / fortran / 4351 < prev    next >
Encoding:
Text File  |  1992-11-18  |  3.9 KB  |  86 lines
  1. Newsgroups: comp.lang.fortran
  2. Path: sparky!uunet!stanford.edu!unixhub!slacvx.slac.stanford.edu!fairfield
  3. From: fairfield@slacvx.slac.stanford.edu
  4. Subject: Re: FORTRAN character strings (LONG)
  5. Message-ID: <1992Nov18.104932.1@slacvx.slac.stanford.edu>
  6. Lines: 74
  7. Sender: news@unixhub.SLAC.Stanford.EDU
  8. Organization: Stanford Linear Accelerator Center
  9. References: <1992Nov18.155753.20537@alw.nih.gov>
  10. Date: Wed, 18 Nov 1992 18:49:32 GMT
  11.  
  12.     The following is a somewhat lengthy response to a question applicable
  13. only to VAX FORTRAN.  If you're not interested, skip it now :-)
  14.  
  15. In article <1992Nov18.155753.20537@alw.nih.gov>, plugge@faxcsl.dcrt.nih.gov writes:
  16. >    How gross is the following STRING structure.  I'd like to
  17. >    develop some string functions are a structure.  Should I
  18. >    stick with ASCIZ or a character string and length format
  19. >    instead of the following -
  20. >
  21. >    Integer        Charlength
  22. >    Parameter    (CharLength=132)
  23. >
  24. >    Structure    /String_Type/
  25. >
  26. >      Union
  27. >        Map
  28. >          Character*(CharLength)    Char
  29. >        End Map
  30. >        Map
  31. >          Byte            Byte(CharLength)
  32. >        End Map
  33. >      End Union
  34. >      Integer            Length
  35. >
  36. >    End Structure
  37.  
  38.     The answer to your question depends entirely on your application. The
  39. structure you've defined is perfectly fine if your application requires a
  40. character buffer (Byte) argument as opposed to a character string descriptor
  41. argument (Char).  For instance, I could imagine calling a FORTRAN 66 routine
  42. that required a Hollerith argument rather than character (but see below).
  43.  
  44.     I presume you are aware (yes?) that VAX FORTRAN passes all arguments by
  45. reference (pointer) _except_ character arguments.  The latter are passed by
  46. _descriptors_, which are themselves structures.  (That is, the address of a
  47. structure called a descriptor is passed, rather than the address of the
  48. array of character bytes.)  For FORTRAN calls, I can't see any point in your
  49. structure.
  50.  
  51.     For calls to C-language subroutines, you could use this structure
  52. passing, e.g. SOME_STRING.BYTE as opposed to SOME_STRING.CHAR.  You could
  53. also get away with passing just SOME_STRING since the address of the
  54. structure is the same as the address of the Byte field.  On the other hand,
  55. you can also use the %REF built-in to pass a character variable by reference
  56. without resorting to your proposed structure.
  57.  
  58.     Given that you've constructed this structure, it looks as if you want to
  59. retain the current occupied length of the string in the Length field.  If
  60. you're going to that trouble, then the called routine has to know the
  61. structure of SOME_STRING anyway, why don't you just use descriptors?  In
  62. fact, a "more sensible" structure would omit the Byte field altogether:
  63. the Char field retains in its descriptor the maximum length allowed (FORTRAN
  64. character strings are static: you can't/shouldn't modify the length field
  65. in the descriptor), while the Length field would keep the currently occupied
  66. length of the Char field.
  67.  
  68.     I guess the last issue I hadn't mentioned was that FORTRAN always pads
  69. character variables with blanks while other languages terminate the strings
  70. with one or more null bytes (that's what you referred to above by ASCIZ).
  71. System services seem to pad the full length of the input string with nulls.
  72. C string routines simply terminate the string with a single null.  In the
  73. former case, if the system service doesn't return a length (I'm thinking of
  74. the RTL routine LIB$FIND_FILE), you can use STR$TRIM to return the non-
  75. blank, non-null length.  For a string returned from C, you'd need to use
  76. INDEX to find the first null (equivalence CHARACTER*1 NULL and BYTE BNULL;
  77. initialize BNULL to 0; LENGTH=INDEX(SOME_STRING, NULL) - 1).
  78.  
  79.         Cheers, Ken
  80. --
  81.  Dr. Kenneth H. Fairfield    |  Internet: Fairfield@Slac.Stanford.Edu
  82.  SLAC, P.O.Box 4349, MS 98   |  DECnet:   45537::FAIRFIELD (45537=SLACVX)
  83.  Stanford, CA   94309        |  BITNET    Fairfield@Slacvx
  84.  ----------------------------------------------------------------------------
  85.  These opinions are mine, not SLAC's, Stanford's, nor the DOE's...
  86.