Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!uunet!snorkelwacker!paperboy!meissner From: meissner@osf.org (Michael Meissner) Newsgroups: comp.lang.c Subject: Re: Blessed be the author(s) of Lint Message-ID: Date: 12 Oct 90 16:13:50 GMT References: <3965@goanna.cs.rmit.oz.au> Sender: news@OSF.ORG Organization: Open Software Foundation Lines: 30 In-reply-to: ok@goanna.cs.rmit.oz.au's message of 12 Oct 90 09:35:56 GMT In article <3965@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes: | Path: paperboy!snorkelwacker!usc!samsung!munnari.oz.au!goanna!ok | From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) | Newsgroups: comp.lang.c | Date: 12 Oct 90 09:35:56 GMT | Organization: Comp Sci, RMIT, Melbourne, Australia | Lines: 8 | | Just for a change I thought I'd post something that _wasn't_ a problem. | Lint just caught a mistake in some code of mine where I was shifting | by 32 instead of 5 ("shift greater than size of object"). | Am I _glad_ that I ran lint after typing in every few functions! | No, I'm not a new convert to lint, it's just the first time I've made | this particular mistake in C. Lint saved me a great deal of embarrassment. Especially since shift by 32 gives rather surprising results on MIPS and 88K based systems. MIPS chips just use the 5 bit shift amount, which would mean that you did a shift of 0. The 88k doesn't have a shift instruction, instead it has several extract bit instructions, and uses the next 5 bits for the number of bits, which means that a shift of 32 would extract the bottom bit. Tom Wood found a few bugs in the GCC compiler that depended on doing a shift by 32 returning 0 (these have since been fixed). -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142 Do apple growers tell their kids money doesn't grow on bushes?