home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / os / os9 / 1174 < prev    next >
Encoding:
Text File  |  1992-08-27  |  1.3 KB  |  34 lines
  1. Newsgroups: comp.os.os9
  2. Path: sparky!uunet!usc!sdd.hp.com!think.com!cass.ma02.bull.com!ladcgw.ladc.bull.com!orchard.la.locus.com!optimla!ron
  3. From: ron@optimla.aimla.com (Ron Moore)
  4. Subject: Re: getc() bug?
  5. Message-ID: <1992Aug27.172741.8294@aimla.com>
  6. Sender: news@aimla.com
  7. Nntp-Posting-Host: hematite
  8. Organization: OptImage Interactive Services L.P.
  9. References: <17h1seINNcj4@agate.berkeley.edu>
  10. Date: Thu, 27 Aug 92 17:27:41 GMT
  11. Lines: 21
  12.  
  13. In article <17h1seINNcj4@agate.berkeley.edu> kientzle@beirut.berkeley.edu (Tim Kientzle) writes:
  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.  This is using the libraries supplied with
  17. >the MM/1, which I believe are the OS9 2.3 libraries.  Can anyone
  18. >confirm or deny that getc() has a problem?  And, if so, can
  19. >anyone suggest a simple workaround (other than re-arranging the code,
  20. >preferably).
  21. >                    - Tim
  22.  
  23. Howdy,
  24.     All of the OS9 system calls reserve D1 for returning error codes on
  25. failure.  Many support routines for system calls take advantage of this
  26. and use D1 as a temporary variable.  How did this show up for you?
  27. The Microware compiler knows better than to rely on holding onto D1.
  28. Are you using GNU?
  29.  
  30. -- 
  31.                 Ron Moore
  32.                 OptImage Interactive Services Co., L.P.
  33.                 uunet!aimla!optimla!ron
  34.