rb@ccird1.UUCP (Rex Ballard) (05/09/86)
This is just one more argument for lint. True, lint often burps over "trivial" little problems like passing a *int to a function that expects *char, among others, but there are some real good reasons for using lint. Frequently, after working on a project for several months and coming up with a working system, it gets passed to someone else. That someone else then has to make a small enhancement that affects only one module out of 100. This second person might not understand that this *int is not really a pointer to integers, but is in fact a pointer to some more complex type. By putting the casts, VARARGS, NOSTRICTS, et al, the new guy at least gets a warning that something is not what it appears to be. This is particularly important if I do something like us an int as a pointer to char (yuckkk!!! :-). Now, if either he or I induce a new bug, or something that might need explanation, lint is there finding that "1/5" of the wierdness that might have gone wrong. Even more important is when we switch compilers, go to cross-tools, or use some other change in the environment. If the thing has been linted, casted, and cleaned up, we can ASK it to tell us about "dubious casts", or whatever and have a better idea of why things don't work as well. When someone comes up with the "lint cramps my style" arguments, I tend to get worried. When I get handed some code that has to be "ported" or enhanced, I run lint on it before I do anything. If lint goes crazy, I know I will have to read ALL of the code before I can do anything. There are a lot of cute "tricks" you can do with C, like setting "pointers" that are really integers. But if you want to do this, you should be explicit in defining "(char *)0x2300ffff". Believe it or not, I have actually seen code that legitimately calls address location 0 (useful on the 8085). This is guarenteed to drive a programmer crazy if he tries to port this to another machine. I also expect a programmer to run code through lint before he gets my help. I have spent too many hours with people who insist the compiler is broken because they have tried to, in effect, build an array in the operating system vector space :-). If he really WANTS to build an array in the operating system vector space, he should SAY SO, not just to me, but to lint. I find it amazing that an employer would pay a programmer for three days worth of debugging using ODT (octal debugging toy) to test and debug code when all but one hours worth could be found in a 2 hour session of lint/vi. Real Programmers CAN use the "front panal", but they won't if there is a faster easier way! If you are programming on your own time, and don't have any plans for releasing your code to anyone, then don't use lint. But if you want to "publish" your little gem, the $95 for lint on a "PC" will easily offset the $20/hr*20 or thirty hours someone might spend getting it to run on their "not quite compatible". This is especially true on 68K machines where Ints can be short and pointers can be long and (*char)i can do some really nasty things. Sure it's possible to use the "long int switch", but then the program runs 150% slower.
davidsen@steinmetz.UUCP (Davidsen) (05/22/86)
In article <411@ccird1.UUCP> rb@ccird1.UUCP (Rex Ballard) writes: >This is just one more argument for lint. > >True, lint often burps over "trivial" little problems like >passing a *int to a function that expects *char, among others, >but there are some real good reasons for using lint. > These are *NOT* trivial problems! This is the type of things which destroys portability. On a number of machines, the format of a data pointers is not at all the same, and passing a wrong type pointer may break the program completely. These machines include Honeywell (I bet you care), DG, and Cray. I was part of X3J11 for two years and had it beaten into me why we needed the "void *" pointer and forced casts. If you think these are trivial problems you perhaps lack experience with a wide enough variety of machines. Portability is the *best* reason for lint. There are better debugging tools available these days. -- -bill davidsen ihnp4!seismo!rochester!steinmetz!--\ \ unirot ------------->---> crdos1!davidsen / sixhub ---------------------/ (davidsen@ge-crd.ARPA) "Stupidity, like virtue, is its own reward"