cck@deneb.ucdavis.edu (Earl H. Kinmonth) (07/31/89)
[header lost, sorry] >Personally, I went on a prototype kick for about six months about two >years back. Everything was strictly prototyped, and I had a set of >standard macros to elide the prototypes for lint. I would say that >during this entire time, prototypes provided me absolutely no benefit >whatsoever. I went the opposite direction, a lint kick, if you will, and this produced <extreme frustration> and not much else. (If any of my comments are totally inappropriate by virtue of being based on 286 experience, don't flame. Rather send your spare change to the Fund-To-Buy-Me-A-386.) (a) lint messages come in half a dozen different formats, none of which is particularly essay to integrate into the source text (and SCO xenix does not include the Berkeley style 'error' program to do this for you); (b) lint breaks regularly (runs out of core, stops saving messages) on source files that the compiler is perfectly happy with; (c) lint does not really provide portability warnings for coding that regularly causes me problems (big vs little endian machines, far, near usage, etc.); (d) on my (286) machine, lint is even slower than the large model of the compiler, which is to say ssslllooowww. Rather than using lint, I find it much more efficient to move my code to MSDOS and run it through Turbo C with all the warnings turned on. The ratio of significant warnings to chaff is higher than for lint, and changes are easier. I've even done this with useful effect for code that could not possibly run under **IX. As for prototypes, they've saved my butt a number of times. Unfortunately, this has usually happened after I'd wasted an hour or two before I heeded the warning that some function did not have a prototype --- and the problem turned out to be a subtle parameter mismatch.
davidsen@sungod.crd.ge.com (William Davidsen) (07/31/89)
I use prototypes all the time. I even wrote a little package to generate the prototype files which I include as .h files in my programs. lint is a neat tool, but it has three shortcomings: 1) it doesn't find all the problems 2) it finds non-problems 3) it doesn't fix any problems (where protypes cause coersion) Therefore lint by itself is not a complete solution. I usually run with prototypes and pass lint of a program when it's about to go into another production release. I like the MSC/Xenix compilers with the warnings turned up, although you may have to filter out some which are not meaningful in most cases. Prototypes can be left in a program, while lint is a tool rather than a part of a well designed program. I use both, but I find prototypes catch more errors, since I don't have to run an extra step to see the errors. bill davidsen (davidsen@crdos1.crd.GE.COM) {uunet | philabs}!crdgw1!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
gors@well.UUCP (Gordon Stewart) (07/31/89)
Presumably, prototypes will enable compilers to implement most of the features of lint, including portability checking. In any case, they do give the compiler more ammunition. I currently have to struggle with an old versioon of lint - and, like the story of the boy who cried "Wolf", I usually ignore the output now! -- {apple, pacbell, hplabs, ucbvax}!well!gors gors@well.sf.ca.us (Doolan) | (Meyer) | (Sierchio) | (Stewart)