cURL / Mailing Lists / curl-library / Single Mail


Re: curl_easy_escape() and curl_easy_unescape() length arguments data types

From: Daniel Stenberg <>
Date: Tue, 15 Jan 2008 20:15:37 +0100 (CET)

On Tue, 15 Jan 2008, Yang Tse wrote:

>> if we change it for the next SONAME bump instead we might rather start to
>> cause problems to applications that want to stay portable with multiple
>> libcurl versions...
> But it isn't completely clear to me what you actually try to communicate
> with the above paragraph in the part that starts with "and if we change it
> [...]"

Sorry for being vague.

I meant that if we change to size_t at let's say the next SONAME bump,
applications that are written to work with today's API *and* the next will
have to adapt to the API being int OR size_t when it calls the function and it
thus needs to use #ifdefs or similar.

With the current API, all they need to do is accept the limitation (they can
only pass in data as long as can be expressed in an int) and pass an int.

So, while the current API is bad and size_t is good, I fear that by converting
to the good we force upon apps to have to use _both_ the bad and the good.

  Commercial curl and libcurl Technical Support:
Received on 2008-01-15