[Libevent-users] Patch for trunk to build on mingw, plus a couple of questions.

[Chris Ross]

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