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 ;)


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]

Reply via email to