home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / sgi / 18324 < prev    next >
Encoding:
Internet Message Format  |  1992-12-24  |  2.1 KB
  1. Xref: sparky comp.sys.sgi:18324 comp.sys.sgi.bugs:42 comp.unix.ultrix:9072
  2. Path: sparky!uunet!paladin.american.edu!darwin.sura.net!gatech!swrinde!sdd.hp.com!network.ucsd.edu!news.service.uci.edu!draco.acs.uci.edu!iglesias
  3. From: iglesias@draco.acs.uci.edu (Mike Iglesias)
  4. Subject: Re: tempnam(3S) bug, possibly on all MIPS
  5. Nntp-Posting-Host: draco.acs.uci.edu
  6. Message-ID: <2B394E9C.23063@news.service.uci.edu>
  7. Newsgroups: comp.sys.sgi,comp.sys.sgi.bugs,comp.unix.ultrix
  8. Organization: University of California, Irvine
  9. Lines: 33
  10. Date: 24 Dec 92 05:46:04 GMT
  11. References: <1gu849INNp6k@menudo.uh.edu> <tqcnepk@zuni.esd.sgi.com> <1992Dec24.011451.497@pixar.com>
  12.  
  13. In article <1992Dec24.011451.497@pixar.com> aaa@pixar.com (Tony Apodaca) writes:
  14. >In an article, murphy@ufp.dco.dec.com (Rick Murphy) writes:
  15. >>Looking at errno after calling a library routine that hasn't failed isn't
  16. >>a useful thing to do. The call succeeded - you've got no reason to go looking
  17. >>at errno.
  18. >
  19. >    This is not really the point.  The point is that a smart programmer
  20. >checks errno after every system call.
  21.  
  22. Yes, it is the point.  Here's an excerpt from the Ultrix errno(2) man
  23. page:
  24.  
  25.      The errno external variable is set when an error occurs in a system
  26.      call.  You can use the value stored in errno to obtain a more detailed
  27.      description of the error than is given in the system call's return
  28.      value.  The errno variable is not cleared on successful system calls, so
  29.      you should check its value only when an error is reported.
  30.  
  31. The Sun intro(2) man page says essentially the same thing.
  32.  
  33. >errno had
  34. >been set as a side-effect of tmpnam() in a different module in a different
  35. >file hundreds of lines of code ago.  This is totally unexpected (and
  36. >I might add totally undocumented) behavior, and it is a pain in the butt.
  37.  
  38. It is documented, as noted above.
  39.  
  40.  
  41. Mike Iglesias                        Internet:    iglesias@draco.acs.uci.edu
  42. University of California, Irvine     BITNET:      iglesias@uci
  43. Office of Academic Computing         uucp:        ...!ucbvax!ucivax!iglesias
  44. Distributed Computing Support        phone:       (714) 856-6926
  45.  
  46.