Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!rochester!cornell!batcomputer!rpi!zaphod.mps.ohio-state.edu!think.com!spool.mu.edu!uunet!olivea!apple!veritas!amdcad!dgcad!dg-rtp!hunt From: hunt@dg-rtp.rtp.dg.com (Greg Hunt) Newsgroups: comp.unix.programmer Subject: Re: sscanf always generates error condition Message-ID: <1991May2.134354.9719@dg-rtp.dg.com> Date: 2 May 91 13:43:54 GMT References: <1991Apr30.233554.1321@agate.berkeley.edu> <1991May1.024357.7750@dg-rtp.dg.com> <1991May1.193252.16232@agate.berkeley.edu> Sender: hunt@hobbit (Greg Hunt) Reply-To: hunt@dg-rtp.rtp.dg.com Distribution: usa Organization: Data General Corp., Research Triangle Park, NC Lines: 51 In article <1991May1.193252.16232@agate.berkeley.edu>, ilan343@violet.berkeley.edu (Geraldo Veiga) writes: > First of all, thank you for all postings and mail helping me with > this question. You're welcome. Me>In the test case, errno is being used without having a value assigned to Me>it, so the "9" is just garbage that happened to be in the memory Me>associated with errno at the time. On the other system you tried, the Me>garbage happened to have been zero, so everything worked. GV> This was not the case. In the ISC system call errno=0 (or whatever I GV> set it to) before and errno=9 after. Also, sscanf returns 1 GV> (as it should in my example). That's wierd. Since the return value is correct, then I would guess that the errno being set to 9 is meaningless. I would have expected it to not be set at all, however. Obviously on the ISC system, it's being handled differently. GV> This problem came up because I have a generic error message function GV> used for both system and user errors. This function always checks the GV> value of errno and prints whatever system error message was indicated GV> (with a perror() call). GV> GV> From the discussion in this and one previous posting, this doesn't seem GV> a like very good idea, since a system call could set the value of errno GV> to some misleading value that would generate a non-related message GV> next time I print a user error message. The common error handling is a great idea! Don't throw it away! Just change the code after a system call or library call to check the return value to detect if an error occurred first, then call your common error handler to print the error out (and shutdown the process, or whatever else it does). This is exactly how I use the common error handler that I have in my own code, and it works great. GV> I was aware that the it wouldn't set errno=0, but setting it to a GV> non-zero value on normal termination still bothers me. It would bother me, too. It might be a bug in the ISC sscanf library call (albeit a fairly harmless one since the function works and does return the proper value). If you're inclined to do so, you might want to check with them about it. Giving them your test case that shows errno is being reset would help them track it down to determine if it really is a bug, or whether it's supposed to be happening. -- Greg Hunt Internet: hunt@dg-rtp.rtp.dg.com DG/UX Kernel Development UUCP: {world}!mcnc!rti!dg-rtp!hunt Data General Corporation Research Triangle Park, NC, USA These opinions are mine, not DG's.