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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list