home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / sys / hp / 9243 < prev    next >
Encoding:
Internet Message Format  |  1992-08-13  |  2.5 KB
  1. Xref: sparky comp.sys.hp:9243 comp.sys.sgi:12337
  2. Path: sparky!uunet!deere!jrh@de.deere.com
  3. From: jrh@de.deere.com (John R. Howell)
  4. Newsgroups: comp.sys.hp,comp.sys.sgi
  5. Subject: Re: Help for my binary read !!!
  6. Message-ID: <1159@deere.com>
  7. Date: 13 Aug 92 12:58:30 GMT
  8. References: <Aug.12.15.40.21.1992.3094@paul.rutgers.edu>
  9. Sender: usenet@deere.com
  10. Followup-To: comp.sys.hp
  11. Organization: Deere & Company
  12. Lines: 51
  13.  
  14. In article <Aug.12.15.40.21.1992.3094@paul.rutgers.edu>, slu@paul.rutgers.edu (shen lu) writes:
  15. >    I have the following c-code which reads in a binary file
  16. >    generated by Fortran program write: write(10) n1,n2,n3,n4
  17. >    (Here, n1=40,n2=60, n3=17, n4=1)
  18. > 
  19. >  Interestingly, the c-code will give me the following results:
  20. >      16 40 60 17  
  21. >      ^^
  22. >      (What's is 16 doing here ? )
  23. > 
  24. > 
  25. >  What's going on ?
  26. >   I tested both code on SGI IRIS and HP 835 machines, they give the 
  27. >   same unmatching results.
  28. > 
  29. >  Could somebody out there give me some hint ?
  30.  
  31.  
  32. Fortran writes binary data as "records". One record for every write.  This
  33. way you can read just the first variable off of every record, just like
  34. you can read the first variable off of every line with formatted i/o.
  35.  
  36. Therefore fortran is "record oriented" which is quite different from C which
  37. doesn't have records.  You just start reading from the beginning.  If you
  38. want a number on a second line, you have to read through everything on
  39. the first line to get to it.
  40.  
  41. OK ... In fortran unformatted io, the file has to know where records start
  42. and end.  There are a number of ways to do this and there doesn't appear
  43. to be much of a standard for this.  Under IRIX, I believe the records start
  44. with a number (4bytes) that tells how many bytes follow for this record. So
  45. for your example you wrote four Integer*4 values which is 16 bytes. Now
  46. when you read the first 4byte integer, you get the size of the record. If
  47. your c code would have read one more integer, you would have picked up the
  48. next integer you were looking for (1).
  49.  
  50. An interesting sidelight ...
  51. I stumbled across this unformatted file record structure back in the old
  52. SGI 3000 days after staring at many a hexdump. That machine stored
  53. records differently by using a special "end of record" character.  If the
  54. "end of record" character appeared in the data somewhere, it was escaped
  55. by a special "escape" character. The current way on the 4D is much
  56. better IMHO and appears to be more consistant.
  57.  
  58. I don't know how HP stores unformatted records.  Perhaps you should do
  59. a couple hexdumps (od).
  60.  
  61. John
  62.  
  63.  
  64.  
  65.