Skip to content

Why does curl_easy_escape need a CURL*? #9115

Answered by jay
TedLyngmo asked this question in Q&A
Why does `curl_easy_escape` need a `CURL*`? #9115
Jul 6, 2022 · 2 answers

I'm building a libcurl wrapper for C++ (yes, yet another one) and want to build a standalone RAII wrapper around curl_easy_escape. That becomes problematic since it requires a CURL*. What's the reason behind that?

I looked in the libcurl source code and curl_easy_escape just discards the struct Curl_easy *data parameter with (void*)data (to avoid a warning about the unused variable). Since the deprecated curl_escape only does return curl_easy_escape(NULL, string, inlength); I assume, although not documented, that calling curl_easy_escape with NULL is ok. I also assume that this added parameter may become important in future releases - so I want to know if there's a plan to use it?

There's a confusing comment above the next function in the source code:

/*
 * Curl_urldecode() URL decodes the given string.
 * 
 * 'data' can be set to NULL
*/
CURLcode Curl_urldecode(const char *string, size_t length,
                        char **ostring, size_t *olen,
                        enum urlreject ctrl)

Curl_urldecode doesn't have a parameter named data, but curl_easy_unescape who calls Curl_urldecode does - which it discards just like curl_easy_escape. Should the comment simply be moved/copied to curl_easy_escape to curl_easy_unescape?

Is it safe to assume that calling both curl_easy_escape and curl_easy_unescape with the CURL* set to NULL will work in future releases?


In the commit where curl_easy_escape was introduced, the CURL* was actually used depending on #ifdef CURL_DOES_CONVERSIONS - but that has since been removed. If it's in fact a legacy parameter but the "new" function is is kept as-is for backwards compatibility, wouldn't it be good to de-deprecate curl_escape/curl_unescape (and remove "This function will be removed in a future release" from the documentation) - or add a new pair:

char *curl_easy_escape2(const char *string, int inlength);            // curl_easy_escape + curl_escape forwards to this
char *curl_easy_unescape2(const char *string, int length, int *olen); // curl_easy_unescape + curl_unescape forwards to this

I'm starting my vacation Today so if adding a new pair sounds like a good idea, I can do the bulk of the work :-)

Curl_urldecode doesn't have a parameter named data

Fixed in 30c8625, thanks.

Is it safe to assume that calling both curl_easy_escape and curl_easy_unescape with the CURL* set to NULL will work in future releases?

I've proposed #9121 to address this.

Replies

2 suggested answers

Curl_urldecode doesn't have a parameter named data

Fixed in 30c8625, thanks.

Is it safe to assume that calling both curl_easy_escape and curl_easy_unescape with the CURL* set to NULL will work in future releases?

I've proposed #9121 to address this.

0 replies
Answer selected by bagder

I think we should keep the one that takes a curl handle just in case we come up with a new use for it again in the future.

0 replies
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Category
Q&A
3 participants