Re: Exporting strlcat()?

From: Date: Thu, 01 Jan 1970 00:00:00 +0000
Subject: Re: Exporting strlcat()?
References: 1  Groups: php.dev 
Request: Send a blank email to php-dev+get-55589@lists.php.net to get a copy of this message
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. > 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. 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. > 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. > 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. I'll probably make the same fix for this function as the one mentioned above. > 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. -- Daniel Stenberg - http://daniel.haxx.se - +46-705-44 31 77 echecho xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'ol

« previous php.dev (#55589) next »