Path: utzoo!utgpu!watmath!clyde!att!rutgers!mailrus!ames!haven!adm!smoke!gwyn From: gwyn@smoke.BRL.MIL (Doug Gwyn ) Newsgroups: comp.lang.c Subject: Re: const, volatile, etc Message-ID: <9051@smoke.BRL.MIL> Date: 3 Dec 88 08:39:51 GMT References: <674@quintus.UUCP> <117@halcdc.UUCP> <468@auspex.UUCP> <9033@smoke.BRL.MIL> <10929@ulysses.homer.nj.att.com> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB)) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 52 In article <10929@ulysses.homer.nj.att.com> ggs@ulysses.homer.nj.att.com (Griff Smith) writes: >Good start. Now, what do I do about upgrading a million lines of old >code to the new standard, and finding all the mis-declared variables. You could do what I've had to do for each release of UNIX from AT&T: Go through the entire goddamn source code and fix everything the hard way. I have a small list of things I look for that catch most poor practices. Here are some of them: char c; // look for a following (c = getc()) sig* // signal handling is almost always wrong unlink( // add check first for null filename pointer argv // check argc first /*VARARGS*/ // usually doesn't use error // may need to be varargs-ized #if // check that conditionalization is right u3b // usually a 3B-only kludge instead of a fix gets( // usually used unsafely strc..( // often used unsafely scanf( // often used wrong BUFSIZ // usually indicates an unsafe assumption execl*( // terminator usually needs cast unsigned // sometimes mixed expressions need casts // look at EVERYthing that "lint -p" squawks about: read( // buffer address usually needs cast write( // buffer address usually needs cast malloc( // declaration often missing lseek( // declaration often missing time( // declaration often missing exit( // declaration often missing free( // declaration often missing perror( // declaration often missing return; // often missing value What I don't know is why AT&T didn't do all this a long time ago. For the $80,000 or so we have to pay for a source license, it is reasonable to expect good quality control to have been applied. As to changes brought on by a new release of a C compiler, there is no easy way to be sure what compiler-dependent assumptions were made in existing code. The specific problem you mentioned concerning data shared with an asynchronous signal handler can be searched for fairly readily by grepping for use of signal() then hunting down the handlers and see just what they do (not very much in most cases). Add "volatile" to shared flags, and consider using type sig_atomic_t for them (which you need to typedef yourself for non-__STDC__). UNIX PCCs have used a variety of techniques to prevent hyperoptimization of accesses to potential device registers in compiling device drivers. For example, one I know of knew what hardware addresses were used for device registers and disabled such optimization for them. Many device drivers are still critically dependent on the way the code generator works, so they need to be reviewed EVERY time the code generation changes.