On Nov 21, 2006, at 8:23 PM, Niels Provos wrote:
3) http.c uses strlcpy, so libevent adds a strlcpy implementation
when
the platform doesn't have one. This is fine, except for the fact
that the strlcpy implementation is actually exported by libevent:
later, when I use autoconf to detect whether strlcpy is available,
I need to make sure to do so before I search for libevent, so that
I don't erroneously pick up libevent's strlcpy implementation.
That's going to be pretty easy, right?
In this sort of situation, I think the answer should be to change
libevent so that it doesn't export strlcpy(). IMHO, it's wrong for a
non-libc library to export a function with the same name as one that
exists in other libc's. I would recommend changing libevent so that
if the system doesn't provide a strlcpy, such that it needs to make
it's own, that it name it something else and #define strlcpy to it
inside of http.c. Whether or not that function is exported outside
of libevent becomes less important, in that case.
Reasonable suggestion?
- Chris
_______________________________________________
Libevent-users mailing list
Libevent-users@monkey.org
http://monkey.org/mailman/listinfo/libevent-users
