LAST ARCHIVE

ARCHIVES INDEX

NEXT ARCHIVE

C, LINT AND CONFUSION

Jim Butterfield

(This article was first published in the ICPUG Journal September/October 1992 issue.
Permission from Jim Butterfield to republish on the Internet has been received.)

C is a forgiving, (some say sloppy), language. A close cousin to the C language is a program called LINT, which looks through your C code in a very unforgiving way. What it finds may be of interest, even to users who don't program in the C language. Lint is a standard command on UNIX systems; it was developed along with C. The only version of Lint that I know of for the Amiga is FlexeLint, by Gimpel Software. Put Lint to work on one of your successful C programs and you're likely to get hundreds, (thousands?), of messages telling you what you're doing wrong. Faced with a litany of complaints about your formerly perfect coding, you might decide on any of several options:

1. throw Lint away and return to your blissful pre-Lint state;
2. never again run Lint on your own source programs, but only on other people's, then complain about their code;
3. try to read ALL those messages, which will keep you out of the new-programming arena for a year or so;
4. investigate some of the things that Lint is telling you about C. Among the nit-picking complaints you'll find some interesting insights into the workings of the Amiga, and Commodore for that matter. I'll pick a couple of them.

If you've muddled about in technical matters, you probably know that a byte can contain an integer value from O to 255. Well, only if it's unsigned, otherwise it can contain an integer value from -128 to +127. A rose by any other name? Not exactly. When you compare two bytes to see which is greater, the results might be different depending on whether the bytes contain signed or unsigned values. God help you if you have one of each. In typical C compilers a number is signed unless you specify it as unsigned. Most barefoot coders don't bother about the rules. You want the size of a file; get it from structure FileInfoBlock, where it occupies 4 bytes. Add, subtract, compare and don't worry about signs. they will only become important if your file contains over 2,147,483,647 bytes. That's a bit too much for my hard disk at the moment. But. . . that means that Commodore reports file sizes as signed numbers. Hmmm. Wonder what a file of size -300 bytes looks like? Meanwhile, your C program, steams along, happily doing signed arithmetic on these numbers, and cheerfully throwing away the sign when you transfer a value into an unsigned environment. It all works and you won't get a peep of protest out of the C language. But Lint complains bitterly about all this, noting that your code just threw away a sign bit... or, going in the other direction, you just "lost precision", which means your value had to make room for a sign bit.

In the same way, Lint shouted loudly about, not my code, but Commodore's "include" files. Gosh, they always worked for me... at least, those parts that I made use of. (Include files are massive, and typical programs make use of less than 1% of the material they call in). Lint's complaints were seemingly endless. For example, in examining Commodore file "includes/clib/exec.protos.h", Lint indicated that almost a dozen extra ''#Includes" should have been, well, jncluded. I don't want to go on about it to the extent that Lint does, so I'll give one example. The file contains details about calls to a function Allocate(); as it happens, that's a function I never use. Lint says it's defined wrongly: its first calling value is a pointer to a structure called MemHeader, and that structure hasn't been defined. Near the beginning of the file, there should have been a line such as "#include exec/memory.h".

I started to feel better about being savaged by Lint when I realised that it had more complaints about Commodore's code than about mine. I also started to realise that there's a strange interaction between permissive C and sloppy me. The C compiler silently glides by some rather lumpy areas. It covers for me when I ramble between signed and unsigned numbers. It makes no objection when an include file contains vague coding, providing I don't try to use that part of the file. It generates workable code from what some might call untenable source. But I liked it better before Lint told me how messy it all was. I'd much rather think of my programs as pristine and polished.

This article was reprocessed from the ICPUG Journal by Ken Ross.

TOP