Re: Non-constness of field "data" in "struct curl_blob" with setopt
On 2/22/2021 12:39 PM, Tomalak Geret'kal via curl-library wrote: On 22/02/2021 16:43, Laurent Dufresne via curl-library wrote: -Original Message- From: curl-library On Behalf Of Tomalak Geret'kal via curl-library Sent: Monday, February 22, 2021 5:16 PM To:curl-library@cool.haxx.se Cc: Tomalak Geret'kal Subject: Re: Non-constness of field "data" in "struct curl_blob" with setopt Why? The data isn't going to be modified. Just cast to `void*`. The `const` is erased just like the `char` is in this particular use case. I think we overall agree about how it should be used (cast it void* and if you want a copy, cast it to void* + use the flag), but the API doesn't carry that. Think of "memcpy". The destination is "void*" and gets written to. The source is "const void*". In fact, the compilers may raise a warning (depending on warning level) if you try to assign a "const char*" to a "void*", but not if you assign to a "const void*". A cast (an explicit conversion) tells the compiler "I want this conversion please" and there should be no warning. As I say, it would be best if the documentation were expanded to guarantee the immutability of what you pass it, and a curl_const_blob would make for a clearer interface where this immutability guarantee is enforced for us by the language, but in its absence I'm not sure I see any concrete problem here? If you're concerned about what might happen to your const data, you can set CURL_BLOB_COPY on and then the resulting [non-const!] buffer belongs to curl anyway. Proposed fix at https://github.com/curl/curl/pull/6643 --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
Re: Non-constness of field "data" in "struct curl_blob" with setopt
On 22/02/2021 16:43, Laurent Dufresne via curl-library wrote: > -Original Message- > From: curl-library On Behalf Of Tomalak > Geret'kal via curl-library > Sent: Monday, February 22, 2021 5:16 PM > To: curl-library@cool.haxx.se > Cc: Tomalak Geret'kal > Subject: Re: Non-constness of field "data" in "struct curl_blob" with setopt > >> Why? The data isn't going to be modified. Just cast to `void*`. The `const` >> is erased just like the `char` is in this particular use case. > I think we overall agree about how it should be used (cast it void* and if > you want a copy, cast it to void* + use the flag), but the API doesn't carry > that. > Think of "memcpy". The destination is "void*" and gets written to. The source > is "const void*". > In fact, the compilers may raise a warning (depending on warning level) if > you try to assign a "const char*" to a "void*", but not if you assign to a > "const void*". A cast (an explicit conversion) tells the compiler "I want this conversion please" and there should be no warning. As I say, it would be best if the documentation were expanded to guarantee the immutability of what you pass it, and a curl_const_blob would make for a clearer interface where this immutability guarantee is enforced for us by the language, but in its absence I'm not sure I see any concrete problem here? If you're concerned about what might happen to your const data, you can set CURL_BLOB_COPY on and then the resulting [non-const!] buffer belongs to curl anyway. Cheers --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
RE: Non-constness of field "data" in "struct curl_blob" with setopt
-Original Message- From: curl-library On Behalf Of Tomalak Geret'kal via curl-library Sent: Monday, February 22, 2021 5:16 PM To: curl-library@cool.haxx.se Cc: Tomalak Geret'kal Subject: Re: Non-constness of field "data" in "struct curl_blob" with setopt > Why? The data isn't going to be modified. Just cast to `void*`. The `const` > is erased just like the `char` is in this particular use case. I think we overall agree about how it should be used (cast it void* and if you want a copy, cast it to void* + use the flag), but the API doesn't carry that. Think of "memcpy". The destination is "void*" and gets written to. The source is "const void*". In fact, the compilers may raise a warning (depending on warning level) if you try to assign a "const char*" to a "void*", but not if you assign to a "const void*". I'm not sure how much sense it make to change the API now, so maybe documenting it is enough. Maybe I'm also missing some general "guidelines" about "curl_easy_setopt" which guarantee that the parameters won't be modified by "curl_easy_setopt". Also sorry about the non-utf8 characters. :( Hopefully my mail client is correctly configured now. Cheers, Laurent --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
Re: Non-constness of field "data" in "struct curl_blob" with setopt
On 22/02/2021 15:21, Laurent Dufresne via curl-library wrote: > > Hi everyone, > > > > Version 7.71.0 of libcurl added few more options to enable > user to easily use Mutual TLS. > > Two of them, namely CURLOPT_SSLCERT_BLOB and > CURLOPT_SSLKEY_BLOB, take a “struct curl_blob” as > parameter and this structure has a pointer to the data > with type “void *”. > > A very common case is to have a “const char *” that point > to a PEM formatted string and in such case one would have > to make a non-const copy to correctly/safely use the API. > Why? The data isn't going to be modified. Just cast to `void*`. The `const` is erased just like the `char` is in this particular use case. I suppose there could have been a similar curl_const_blob for cases like this, which might be a clearer design. Or https://curl.se/libcurl/c/CURLOPT_SSLCERT_BLOB.html could be enhanced to guarantee that the blob data is not altered. > This is even more awkward when using “CURL_BLOB_COPY”, > because the user would theoretically have to do a copy to > a “char *” or “char[N]” to leverage the copy. > I don't follow this. If you want the data to be copied, you set `CURL_BLOB_COPY` and the data is copied, using the length you set in the blob. If you don't, don't. What do you need to "leverage"? Maybe I'm missing something... Cheers --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
Non-constness of field "data" in "struct curl_blob" with setopt
Hi everyone, Version 7.71.0 of libcurl added few more options to enable user to easily use Mutual TLS. Two of them, namely CURLOPT_SSLCERT_BLOB and CURLOPT_SSLKEY_BLOB, take a "struct curl_blob" as parameter and this structure has a pointer to the data with type "void *". A very common case is to have a "const char *" that point to a PEM formatted string and in such case one would have to make a non-const copy to correctly/safely use the API. This is even more awkward when using "CURL_BLOB_COPY", because the user would theoretically have to do a copy to a "char *" or "char[N]" to leverage the copy. It seems slightly strange and I was wondering if this was indeed a requirement or something that could be change or be documented? Cheers, Laurent --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
