home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / pascal / 4880 < prev    next >
Encoding:
Text File  |  1992-08-16  |  1.7 KB  |  51 lines

  1. Newsgroups: comp.lang.pascal
  2. Path: sparky!uunet!munnari.oz.au!metro!seagoon.newcastle.edu.au!cis1005.newcastle.edu.au!sbarr
  3. From: sbarr@nyx.cs.du.edu (Sam E. Barr)
  4. Subject: Re: Problems with IOResult (TP.6)
  5. Message-ID: <sbarr.1.714023372@nyx.cs.du.edu>
  6. Sender: news@seagoon.newcastle.edu.au
  7. Organization: Uni of Newcastle, Australia
  8. References: <h07mcp=.gabriel@netcom.com>
  9. Date: Mon, 17 Aug 1992 03:49:32 GMT
  10. Lines: 39
  11.  
  12. In article <h07mcp=.gabriel@netcom.com> gabriel@netcom.com (Gabriel Beccar-Varela) writes:
  13.  
  14. >I have problems with the IOResult function. It gives me a non-zero result
  15. >when I know positively that there is no I/O problem (I confirmed this by
  16. >running the same code with IOResult commented out). I suspect that my disk
  17. >cache is causing the problem. The IOResult function works if I do a dummy
  18. >call to it before calling it for real. Like this:
  19. >         error := IOResult;
  20. >         {$I-}
  21. >         rewrite(f);
  22. >         {$I+}
  23. >         if IOResult <> 0 then ...
  24. >Any suggestions?
  25.  
  26. The problem here is that TP store the IOResult variable until you read it, 
  27. after which it clear it.  So if you make a call to a function which returns 
  28. a non-zero IOResult, and then call another i/o function without first 
  29. reading, and thus clearing IOResult, you still get a non-zero result, 
  30. regardless of the result of the second function.
  31.  
  32. The other problem arrising from this is that you cannot use a call such as
  33.  
  34.    if IOResult <> 0 then
  35.      if IOResult = 8 then ....
  36.  
  37. because the IOResult is cleared after you read it the first time, and thus 
  38. will be zero for the next read.
  39.  
  40. I'll leave it up to you to decide whether this is a bug or a feature, but 
  41. for my mind it is a pain in the neck either way!!   :(
  42.  
  43. >Thank you.
  44. Your Welcome!
  45.  
  46.   Sam Barr
  47.     sbarr@nyx.cs.du.edu
  48.