Daniel Stenberg wrote:
> On Wed, 16 May 2001, Sterling Hughes wrote:
>
> [Talking about strlcat() as it exists globallly in libcurl that then collides
> with the PHP internal one when building PHP with curl]
>
>
>>>Yes, I _could_ rename the strlcat() function to something else, but that
>>>would not be a really satisfactory solution for me, since the function is
>>>indeed used by people and it will be assumed to be around.
>>>
>>When did you add strlcat()? I only have this problem with 7.7.3.
>>
>
> libcurl's strlcat() has been around longer than that. It first appeared in
> 7.6.1, back in february this year.
>
Its odd that I'm just having this problem now then (actually the whole
problem seems a bit suspicious of something else being wrong, either
with PHP or cURL or my system ;).
>
>>If its the internal code-base of cURL your worried about, the patch I
>>sent you declaring it 'static inline' should make the function accessable
>>within cURL itself.
>>
>
> Well, to start off with, I can't make it 'inline' indepedent of compiler as
> there is no standard inline keyword for ANSI C. Secondly, I don't really want
> it inlined as that will increase the size of the library with very little
> gain.
>
yeah, ok ;)
you mean there are other systems besides Linux??? Pahh! I'll believe it
when I see it.
> I could make a solution work for me that would name the function
> 'Curl_strlcat' and then I'd have a macro for libcurl code that looks like
> #define strlcat(x,y,z) Curl_strlcat(x,y,z)
>
> I'd consider that an acceptable solution.
>
> Of course, all libs couldn't do what libcurl does like this, as then you
> couldn't link with several of this kind. I realize that.
>
yeah, and I'm sure *some* of them mess with our namespace, that's why
I'm not sure why this is happening.
>
>>I also think that curl shouldn't be exporting a function like strlcat()
>>simply because the purpose of cURL is not that of a general purpose
>>library, but rather a library for fetching URL's.
>>
>
> Yes, you're right. But bear in mind that I don't explicitly "export"
> strlcat(), it just happens to be a global symbol in my library that also is
> externally accessible. You can find a long range of other symbols too, that
> I'd rather not have exported but unfortunately they are. That is mostly due
> to the nature of the standard unix library concept.
>
yup. but besides the libc functions, most of them are ns protected.
>
>>If you'll notice strlcpy() is not exported (nm -g libcurl.so | grep
>>strlcpy) from the library, as it is defined in krb4.c not a header file.
>>
>
> It is probably not around in your version because you don't have it built
> with krb4-support enabled, otherwise it will be there.
>
could be ;P
> I'll probably make the same fix for this function as the one mentioned above.
>
That would be cool... Regardless of the current issue, I think they
should be ns protected (of course that might be because it helps me out
if they are :)
>
>>I've CC'ed the php-dev mailing list on this. As I don't know PHP's build
>>system as in depth as some of the people on this list do.
>>
>
> Cc'ed back. Do CC me if you want me to receive replies, I don't subscribe to
> php-dev.
>
Naturally ;)
-Sterling
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
