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<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.
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
