[ale] compile error: strlcpy defined differently in 2 different files, huh ?

[Joe Knapka]

Courtney Thomas wrote:

>Joe,
>
>Three things.....
>
>The last line of my previous post should have read "or" instead of "of".
>
>I don't understand why the application would be using an externally 
>defined strlcpy if it had an internal definition ?
>
>If your nonpareil compiled and mine won't, then your 
>/usr/include/string.h must have a different definition of strlcpy than mine.
>
>What is yours, please ?
>  
>
In fact, my string.h has no definition for strlcpy() at all, and K&R
does not
mention it either.  I'd guess that means it was added to the standard
library
by C99, and nonpareil-0.77 was written for an older ANSI C standard.
Glibc should provide some way of detecting whether recent features
are present (such as a #define _C99 or something like that), so nonpareil
should be patched to notice when strlcpy is present in the library. I'm
no expert on the various incarnations of the C standard, so maybe someone
else can enlighten us further.

This situation is complicated by the fact that the return types differ.
What I'd
do is just change all the occurrences of strlcpy in the nonpareil source to
np_strlcpy. That will avoid the naming issue, while maintaning the behavior
that nonpareil needs.

-- JK