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

[Courtney Thomas]

Thank you Joe.



On Mon, 2006-02-06 at 16:56 -0700, Joe Knapka wrote:
> 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
> 
> 
> 
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://www.ale.org/mailman/listinfo/ale