On 22/02/2021 16:43, Laurent Dufresne via curl-library wrote: > -----Original Message----- > From: curl-library <curl-library-boun...@cool.haxx.se> 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 <t...@kera.name> > 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
