Re: Exporting strlcat()?

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