home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / lang / fortran / 4207 < prev    next >
Encoding:
Internet Message Format  |  1992-11-05  |  3.1 KB
  1. Path: sparky!uunet!gatech!news.ans.net!cmcl2!adm!aos!lapoint
  2. From: lapoint@adios.brl.mil (Claude LaPointe )
  3. Newsgroups: comp.lang.fortran
  4. Subject: RE:  RE:  unformatted output
  5. Message-ID: <1054@aos.brl.mil>
  6. Date: 5 Nov 92 14:01:28 GMT
  7. Sender: news@aos.brl.mil
  8. Lines: 66
  9. Nntp-Posting-Host: adios.brl.mil
  10.  
  11.  
  12. Earlier, I wrote:
  13.  
  14.  >mppa3@syma.sussex.ac.uk (Alan Richardson) writes (text paraphrased):
  15.  >
  16.  >>  using Fortran to produce unformatted output, intend tp use C to read
  17.  >>  back in (via fread).
  18.  >>
  19.  >>          PROGRAM unformatted_test
  20.  >>          REAL*4 value1, value2
  21.  >>          value1=123.4
  22.  >>          value2=298.9
  23.  >>          OPEN(10, FILE='file1', FORM='UNFORMATTED')
  24.  >>          WRITE(10) value1
  25.  >>          WRITE(10) value2
  26.  >>          CLOSE(10)
  27.  >>          END
  28.  >>
  29.  >>  I'm running this on an HP 9000/720 machine with HP-UX 8.07. Instead
  30.  >>  of getting just 8 bytes out (two four-byte floats) I get 24 bytes out;
  31.  >>  Fortran pads output 4 bytes either side.
  32.  >>  `od -c file1' gives:
  33.  >>
  34.  >>  0000000 000000 000004 041366 146315 000000 000004 000000 000004
  35.  >>  0000020 041625 071463 000000 000004
  36.  >>  0000030
  37.  >>
  38.  >>  So how do I get rid of these extra bytes, given that my WRITE statements
  39.  >>  lie on several different lines? The poor C program can't cope!
  40.  >
  41.  >
  42.  >1 - what you are encountering is not uncommon - padding to fill a record,
  43.  >    block, or buffer; or beginning and end of record marks, or some such.
  44.  >
  45.  >2 - given that you really want to proceed in this manner, writing C
  46.  >    code to read the records should not be difficult, IF YOU KNOW
  47.  >    THE EXACT STRUCTURE OF FORTRAN UNFORMATTED OUTPUT RECORDS ON
  48.  >    YOUR MACHINE, AND THE INTERNAL REPRESENTATIONS OF YOUR DATA.
  49.  >    After all, the extremely general purpose "od" is written in C.
  50.  >
  51.  >3 - in general, (there are exceptions) fortran unformatted writes are useful
  52.  >    in and intended to be used in fortran write/read pairs on like hardware
  53.  >    and software architectures, with logically similar i/o lists in both
  54.  >    the read and the write statements. The only reason to do this kind of i/o
  55.  >    is to gain efficiency when dealing with large amounts of data by avoiding
  56.  >    the time spent in formatting. The prices paid are decreased flexibility
  57.  >    and increased volume on the storage medium.
  58.  >
  59.  >4 - unless there are overriding considerations, I would recommend
  60.  >    formatted i/o.
  61.  
  62. Subsequently, concern has been expressed the ability to write formatted
  63. and then read formatted with certainty that the resulting bit pattern
  64. is identical to the original one.
  65.  
  66. Interesting comments on IEEE standards, the quality of their implementation,
  67. and other matters, have been provided by various responders to the original
  68. message.
  69.  
  70. It seems to me that,
  71. as long as the application remains on one machine/software system, and
  72. as long as ugliness in not a concern, one could circumvent the problem
  73. by equivalencing variable/array names of appropriate types and doing
  74. formatted reads/writes, not with edit descriptors appropriate to real
  75. or double precision i/o, but with octal or hexadecimal edit descriptors.
  76. Admittedly, these are non-standard, but they are ubiquitous.
  77.