Re: Newbie problems with lclint
I tried a simple test with an include of that file, and lclint did not complain on Sun Solaris 2.7, but on 2.8, I got this: /usr/include/sys/strft.h:30:26: Parse Error: Suspect missing struct or union keyword: hrtime_t : unsigned int. (For help on parse errors, see lclint -help parseerrors.) This is odd: the test file compiles without complaint, and the preprocessor output from the test produces a file that LCLint 3.0.0.17 does not complain about either. I get the same thing, also under Solaris 2.8. I note that hrtime_t is defined in /usr/include/sys/time.h as longlong_t. Does LClint know about 'long long' yet?
Re: Newbie problems with lclint
Andrew Lister <[EMAIL PROTECTED]> wrote: access.c:73: Unrecognized identifier: strdup Identifier used in code has not been declared. (-unrecog will suppress message) The code compiles, string.h is included, etc, etc. The offending line in access.c is: table[i++] = strdup(tmp); It seems like such a fundamental problem that I feel I must be missing something. strdup() is not defined in the C89 standard, nor in POSIX. It is a common UNIX extension, but extension it is. (It had been around for quite some time before C89 came out; a committee who were willing to gulp down the strtok() camel should not have strained out the strdup() gnat.) If member serves me, strdup() still isn't there in C99. NB: strdup() can fail in exactly the same reason that malloc() can fail, and this is often not checked for. Standard or no standard, it would be a good idea to include it in LClint's string.h. The second one is: /usr/include/arpa/inet.h:52:27: Parse Error: Inconsistent function declaration: in_addr_t : extern ?. (For help on parse errors, see lclint -help parseerrors.) That one's on Solaris only but occurs for some other declarations too. SO WHAT DO THE DECLARATIONS LOOK LIKE? In my Solaris system, line 52 of inet.h is the declaration of inet_aton(), which is not in the manual, Idunno why. The first declaration that mentions in_addr_t is extern in_addr_t inet_addr(const char *); The form of this message strongly suggests to me that there is a call to inet_addr() somewhere _before_ the header is included, in which case "extern int inet_addr()" will be inferred. But in_addr_t is NOT the same as int, and it does matter (because in_addr_t is an unsigned integral type).
Re: Newbie problems with lclint
Andrew Lister wrote: > access.c:73: Unrecognized identifier: strdup > Identifier used in code has not been declared. (-unrecog will suppress > message) As you are running lclint with the strict POSIX lib it does not recognize `strdup'. Not sure whether this is correct, however it is defined in the Unix library. So you'll either have to use the Unix library or put a prototype for lclint only in one of your headers read by the source files using `strdup': #ifdef __LCLINT__ extern char *strdup (char *s) /*@*/ ; #endif /* __LCLINT__ */ [declaration from /path/to/lclint/lib/unix.h] > The second one is: > > /usr/include/arpa/inet.h:52:27: Parse Error: Inconsistent function declaration: This *should* be the same, the header is of course a system header and should thus not be read by lclint. Unfortunately, the socket headers are not in the skip list for lclint versions < 3.0 (alpha), so that lclint will normally not skip these although it has most definitions needed to check your program in the unixlib. So as long as you're not adventurous enough to use the alpha version you may help yourself again with a preprocessor conditional: #ifndef __LCLINT__ #include #endif The code should (but need not necessarily) pass lclint fine. Cheers, Herbert -- Dipl.Ing. Martin "Herbert" Dietze -- / -- [EMAIL PROTECTED] The University of Buckingham -- / - [EMAIL PROTECTED] =+= Katz' Law: Man and nations will act rationally when all other possibilities have been exhausted.
