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 <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).
