[libvirt] [PATCH] util: Make virStringArrayHasString() const-correct

Martin Kletzander mkletzan at redhat.com
Tue Aug 16 20:31:31 UTC 2016

On Tue, Aug 16, 2016 at 07:55:11PM +0200, Andrea Bolognani wrote:
>On Tue, 2016-08-16 at 18:49 +0200, Michal Privoznik wrote:
>> On 16.08.2016 13:40, Andrea Bolognani wrote:
>>>> > The first argument should be const char ** instead of
>> > char **, because this is a search function and as such it
>> > doesn't, and shouldn't, alter the haystack in any way.
>>>> > This change means we no longer have to cast arrays of
>> > immutable strings to arrays of mutable strings; we still
>> > have to do the opposite, though, but that's reasonable.
>> Is it? I mean, we are restricting ourselves and compiler fails to see
>> that. To me 'const char **' is more restrictive than 'char **' therefore
>> there should be no typecast required. But this is the discussion I
>> should have with gcc devels. For some reason, gcc does automatic
>> typecasting to const just for the fist level pointers and not the second
>> one. That's why compilers errors out.
>The reason for this behavior is explained in the C FAQ:
>  http://c-faq.com/ansi/constmismatch.html

Just FYI, so that you know why adding more consts (even to sensible
places) doesn't help in C, I found the answer to my question on stack
overflow [1] very satisfactory and explanatory.


[1] https://stackoverflow.com/questions/35319842/why-c-doesnt-allow-implicit-conversion-from-char-to-const-char-const-and

>It's unfortunate, and very annoying. But I'd rather have
>to perform arguably redundant casts than being bitten by
>that kind of bug down the line :)
>> ACK
>Pushed, thanks!
>Andrea Bolognani / Red Hat / Virtualization
>libvir-list mailing list
>libvir-list at redhat.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20160816/8c511fac/attachment-0001.sig>

More information about the libvir-list mailing list