Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: Deprecated Functions?
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-library <curl-library_at_cool.haxx.se>
Date: Tue, 4 May 2021 08:08:46 +0200 (CEST)
On Mon, 3 May 2021, Weston Schmidt via curl-library wrote:
> I found this commit from a few years ago and wondered if the plan was
> still to remove mprintf() and friends?
Only if we ever decide to break the API, which we will work hard not to...
I think adding them to the API was a mistake to begin with but they're there
now and we're going to support them for as long as we maintain the current
API. (And to make it clear: that mistake was mine)
That's also a reason why they're so badly documented. Lame escuse, I know. One
of these days I'll make sure we get *proper* man pages done for them.
> Do any such plans also apply for the curl_url_*() or strncasecmp?
I presume you mean curl_strequal? That has a similar story, yes. I think it
was wrong to add it, but it's there and we will support it.
I don't know why you'd suspect the URL API to be in the same situation as
that's a fairly new member of the libcurl API family. This is rather an API
that it took a long time for us to introduce and that I think totally belongs
in libcurl and helps applications.
Not that the difference matters much to users. They're in the API/ABI and
we'll support them for as long as possible.
> Forgive me if it is obvious, I seemed to find little in the email
> archive and in the code itself.
It might be a bit hard to find, but the key to it all is found on:
https://curl.se/libcurl/abi.html and this quote:
We are determined to bump the SONAME as rarely as possible. Ideally, we
never do it again.
Date: Tue, 4 May 2021 08:08:46 +0200 (CEST)
On Mon, 3 May 2021, Weston Schmidt via curl-library wrote:
> I found this commit from a few years ago and wondered if the plan was
> still to remove mprintf() and friends?
Only if we ever decide to break the API, which we will work hard not to...
I think adding them to the API was a mistake to begin with but they're there
now and we're going to support them for as long as we maintain the current
API. (And to make it clear: that mistake was mine)
That's also a reason why they're so badly documented. Lame escuse, I know. One
of these days I'll make sure we get *proper* man pages done for them.
> Do any such plans also apply for the curl_url_*() or strncasecmp?
I presume you mean curl_strequal? That has a similar story, yes. I think it
was wrong to add it, but it's there and we will support it.
I don't know why you'd suspect the URL API to be in the same situation as
that's a fairly new member of the libcurl API family. This is rather an API
that it took a long time for us to introduce and that I think totally belongs
in libcurl and helps applications.
Not that the difference matters much to users. They're in the API/ABI and
we'll support them for as long as possible.
> Forgive me if it is obvious, I seemed to find little in the email
> archive and in the code itself.
It might be a bit hard to find, but the key to it all is found on:
https://curl.se/libcurl/abi.html and this quote:
We are determined to bump the SONAME as rarely as possible. Ideally, we
never do it again.
-- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://www.wolfssl.com/contact/ ------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2021-05-04