olmstead@syteka.UUCP (THIS SPACE FOR RENT) (11/02/83)
We've run into several annoying bugs in lint running under 4.1bsd on our 750. It appears that either the preprocessor ACTS differently or IS a different program, depending on whether we're cc'ing or lint'ing. For example, lint sometimes complains about a syntax error on lines containing only '#ifdef DEBUG' beginning in column zero. It also sometimes (maybe always, I'm not sure) objects to '#if' lines. Some of the alleged syntax errors occur on '#ifdef' lines that have been disabled by being encased within '#ifdef notdef' lines. Lint also complains randomly about passing NULL (i.e., 0) to functions expecting pointers, so we get to use casts like func(..., (int *)NULL,...) all over the place. All of these "syntax errors" go through cc just fine, thank you. Has anybody fixed these problems? Has anybody else even SEEN these problems? Any advice will be greatly appreciated. Patrick Olmstead ...ucbvax!menlo70!sytek!olmstead ...decvax!sytek!olmstead (when decvax answers the phone)
thomas@utah-gr.UUCP (Spencer W. Thomas) (11/06/83)
Lint properly complains about uncasted NULL pointers in function calls - on some machines (e.g., many 68000 C compilers), ints and pointers are NOT THE SAME SIZE. Thus, a 0 pointer is not the same as a 0 integer, and must be cast in a function call. Note that this is the only place where the compiler will not properly coerce the 0, as it has no knowledge of the receiving argument. There is a known bug in the pre-processor involving #if lines with comments on them (that only shows up when running lint). The solution seems to be to not put comments on #ifs. Lint should never see #ifdef lines, they should be stripped by the preprocessor. If, for some reason, the preprocessor lets one through, it will be for sure diagnosed as a syntax error. Check out your preprocessor, remembering that lint supplies the -C flag to the preprocessor (leave comments in). =Spencer