Andrew Lister <[EMAIL PROTECTED]> wrote:
        access.c:73: Unrecognized identifier: strdup
          Identifier used in code has not been declared. (-unrecog will suppress
        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
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.
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 <arpa/inet.h> 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).

Reply via email to