[PHP-DEV] Re: Exporting strlcat()?

[Sterling Hughes]

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 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: Exporting strlcat()?

[Daniel Stenberg]

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
   ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol




-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: Exporting strlcat()?

[Sterling Hughes]

Daniel Stenberg wrote:

> On Wed, 16 May 2001, Sterling Hughes wrote:
> 
> 
>>  I get the following error when compiling PHP against cURL 7.7.3,
>>any clues?
>>
>>/usr/local/lib/libcurl.a(strequal.o): In function `strlcat':
>>/home/sterling/curl-7.7.3/lib/strequal.c:84: multiple definition of
>>`strlcat'
>>
> 
>>I've attached the config.m4 (configuration file for cURL).
>>
>>Note, that on Linux systems (Mandrake 7.2, kernel 2.4.2 here), we define
>>our own strlcat() and strlcpy() functions, which are slightly modified
>>versions of the OpenBSD implementation.  Also, nm reports that strlcat
>>*is* exported by libcurl...
>>
> 
> How does the PHP configure script figure out that it needs to define its own
> strlcat function?
> 


 From a quick grep of the source, it seems like the AC_REPLACE_FUNCS 
macro is used.


> IMHO, PHP should first figure out what libs it needs and then it should look
> for missing functions to replace with its internal ones.
> 
> That's how libcurl does, but when the configure script in curl runs, it
> doesn't find any strlcat() and thus uses its own version instead.
> 
> 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.

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.

While, I see your point and I somewhat agree with you, 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.  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.


> I figure you could run into problems with curl's own version of strlcpy() as
> well, from the very same reasons.
> 


Well, not as it stands, but if you move it to krb4.h, then yes.


> [ Feel free to forward this mail to whoever in the PHP project that might be
>   interested or have an opinion in the matter. ]


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.

-Sterling



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]