Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: Non-constness of field "data" in "struct curl_blob" with setopt
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Tomalak Geret'kal via curl-library <curl-library_at_cool.haxx.se>
Date: Mon, 22 Feb 2021 17:39:20 +0000
On 22/02/2021 16:43, Laurent Dufresne via curl-library wrote:
> -----Original Message-----
> From: curl-library <curl-library-bounces_at_cool.haxx.se> On Behalf Of Tomalak Geret'kal via curl-library
> Sent: Monday, February 22, 2021 5:16 PM
> To: curl-library_at_cool.haxx.se
> Cc: Tomalak Geret'kal <tom_at_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
Received on 2021-02-22
Date: Mon, 22 Feb 2021 17:39:20 +0000
On 22/02/2021 16:43, Laurent Dufresne via curl-library wrote:
> -----Original Message-----
> From: curl-library <curl-library-bounces_at_cool.haxx.se> On Behalf Of Tomalak Geret'kal via curl-library
> Sent: Monday, February 22, 2021 5:16 PM
> To: curl-library_at_cool.haxx.se
> Cc: Tomalak Geret'kal <tom_at_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
Received on 2021-02-22