From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <18e61d55c20c0b4c1a12231e91b0c831@collyer.net> To: 9fans@cse.psu.edu Subject: Re: [9fans] gcc/plan9 From: Geoff Collyer In-Reply-To: <003301c34b6c$b1fe9ab0$2a8be793@gli.cas.cz> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Date: Wed, 16 Jul 2003 17:10:52 -0700 Topicbox-Message-UUID: f8ff4020-eacb-11e9-9e20-41e7f4b1d025 Testing that *scanf found exactly the number of items you expected is usually the right thing to do. scanf and fscanf can return EOF (-1), so a test against zero will usually be inappropriate. So the last example you gave, if (sscanf(str+(*pos),"%d",&tag)==1) should be used everywhere, including linux (and tag should be an int, not a long nor a short). strings.h is an archaism and shouldn't be needed nor included. All ANSI C implementations (hosted ones, anyway) must provide string.h, and it's been 13 years since the first ANSI C standard, so everybody really ought to have string.h by now. GNU configure and much GNU software go out of their way to support aged or deficient C implementations. I think it's no longer worth worrying about pre-ANSI implementations, except for amusement (e.g., running V7 on a PDP-11 simulator). As for broken implementations, with C News, we found that it was generally better not to contort our code to accommodate bugs in somebody's C implementation, but to publish the bug (perhaps including a pointer to the section of the current C standard that forbids the erroneous behaviour), a test case to demonstrate it, and a workaround, and to distribute the whole bundle widely. Once a vendor realises that it really is his bug and the customers know it and demand a fix, he tends to fix the bug pretty quickly. We found astonishing bugs in production C implementations, some of which had been around for a long time, and I think helped to get them fixed.