Re: [Groff] [PATCH] compiling error on grolbp with latest CVS

[Keith Thompson]

> > lbp.cc:37: declaration of C function `int strncasecmp(const char *,
> >            const char *, int)' conflicts with 
> > /usr/include/strings.h:52: previous declaration `int
> >            strncasecmp(const char *, const char *, unsigned int)' here 
> > 
> > With all evidence, there's a typo in the lbp.cc file. Here's a patch for
> > it:
> > 
> > -#ifdef HAVE_STRNCASECMP
> > +#ifndef HAVE_STRNCASECMP
> >  extern "C" {
> >    // SunOS's string.h fails to declare this.
> >    int strncasecmp(const char *, const char *, int);
> 
> This is the wrong patch.  The very problem is that certain old
> versions of Sun's compiler actually has strncasecmp() but no prototype
> for it.
> 
> The right fix would be to use `size_t' instead of `int'.  Ken, can you
> please check whether `size_t' works?
> 
> Or is there a better solution?
> 
> 
>     Werner

s/Ken/Keith/

Ok, I changed "int" to "size_t" (for the third argument, not the
return type!), and it compiled, linked, and installed without error.

Which is more correct is an interesting question.  There's no
declaration for strncasecmp() in any system header under SunOS 4.1.3.
The man page says:

     int strncasecmp(s1, s2, n)
     char *s1, *s2;
     int n;

Oddly, <sys/stdtypes.h> declares:

    typedef int             size_t;         /* ??? */

(Yes, the ??? is there in the header.)

On SunOS 5.7, the third argument is size_t, which is either unsigned
long or unsigned int:

    #ifndef _SIZE_T
    #define _SIZE_T
    #if defined(_LP64) || defined(_I32LPx)
    typedef unsigned long   size_t;         /* size of something in bytes */
    #else
    typedef unsigned int    size_t;         /* (historical version) */
    #endif
    #endif  /* !_SIZE_T */

In lbp.cc, there's only one call to strncasecmp(), and its third
argument is the literal 4; since all the types in question ([un]signed
(int|long) and size_t) are 32 bits in SunOS 4.1.3, it should work
either way.

BTW, I don't have a Canon CAPSL laser printer, so I can't test
the code.

I'd guess that any system that has a strncasecmp function but doesn't
bother to declare it in a header is likely to use int rather than
size_t for the third argument -- but it's also likely to make int and
size_t the same size.  I'd be inclined to use size_t, and configure
it if a system shows up where size_t doesn't work.

(BTW, strncasecmp is not defined in ISO C; is it POSIX?)

-- 
Keith Thompson, San Diego Supercomputer Center  address@hidden
<http://www.sdsc.edu/~kst/>
Welcome to the last year of the 20th century.