[libvirt] [PATCH] util: Make virStringArrayHasString() const-correct
Michal Privoznik
mprivozn at redhat.com
Fri Aug 19 07:12:44 UTC 2016
On 16.08.2016 19:55, 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
This is very controversial to me. They argue that compiler cannot hold
up to your promise with the following code:
const char c = 'x'; /* 1 */
char *p1; /* 2 */
const char **p2 = &p1; /* 3 */
*p2 = &c; /* 4 */
*p1 = 'X'; /* 5 */
What they are arguing there is that step 3 shouldn't be allowed, because
the compiler cannot hold up to our promise about constness of p2. Well I
disagree. p2 is const char ** which means that only the first level
pointer is const, the second level is pure char *. Therefore in my eyes
it's step 4 where the problem is and where compiler should warn me. I
mean, after I've dereferenced p2, I'm left with 'char *' which I'm
trying to assign address of a const char. IOW:
char * var1 = (const char *) var2;
Obviously, this is not allowed. And compiler has to know what 'const
char **' means, just like what 'char *' means. So I don't really
understand their reasoning there.
Michal
More information about the libvir-list
mailing list