home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / os / os9 / 1178 < prev    next >
Encoding:
Internet Message Format  |  1992-08-29  |  1.2 KB
  1. Path: sparky!uunet!cs.utexas.edu!sun-barr!ames!agate!spam.berkeley.edu!kientzle
  2. From: kientzle@spam.berkeley.edu (Tim Kientzle)
  3. Newsgroups: comp.os.os9
  4. Subject: Re: getc() bug?
  5. Date: 28 Aug 1992 21:43:52 GMT
  6. Organization: University of California, Berkeley
  7. Lines: 20
  8. Message-ID: <17m6moINNaeh@agate.berkeley.edu>
  9. References: <17h1seINNcj4@agate.berkeley.edu> <1992Aug27.172741.8294@aimla.com>
  10. NNTP-Posting-Host: spam.berkeley.edu
  11.  
  12.  
  13. I earlier described:
  14. >>I had this odd bug in a program which I finally solved by moving some
  15. >>calls to getc.  From studying the effect on the assembly, it looks as
  16. >>if getc() is trashing D1.
  17.  
  18. Ron Moore (uunet!aimla!optimla!ron) asks:
  19. > How did this show up for you?  The Microware compiler knows better
  20. >than to rely on holding onto D1.  Are you using GNU?
  21.  
  22.    I'm using the Microware compiler from OS9 2.3 (my distributor
  23. is being rediculously slow about getting 2.4 stuff out), so this
  24. may have been fixed.  The abbreviated, simplified version is that a
  25. statement such as
  26.    wordval = firstbyte * 256 + getc(file);
  27. doesn't work, but 
  28.    wordval = getc(file) + firstbyte * 256;
  29. does.  From the assembly, D1 is being used to hold the intermediate
  30. value, hence my assumption that D1 is being trashed.
  31.                     - Tim
  32.