Why does passing char** as const char** generate a warning?
Short Answer
Can you safely typecast char ** to const char**? No. (Not safely anyway), and the reason is far more subtle than you may think. Can you get rid of it another way? Sure. Load an array of const char* values from your char* values and pass that instead. (or change the callee prototype, but thats cheating =P).
Consider the following code, which essentially does everything you're wishing except invoke a function. The marked line demonstrates the equivalent point-of-cast
const char *s = "Test";
char *p = NULL;
char **pp = &p; // Put address of our pointer in our pointer-to-pointer.
const char **cpp = pp; // Here: assigning char** to const char**
*cpp = s; // perfectly legal; pp and s both finish "char const"
*p = 0; // ru ro raggy
It takes awhile to really stare at this, and admittedly I didn't see it at first either. @sheu did a solid job of catching it about 24 hours before I really thought about it long enough to realize he was right all along (and I actually upvoted that answer before writing this one). Then I thought he was wrong about the same time he thought his answer wasn't applicable. Turns out we were both wrong on that leap, because he was right the first time, I was wrong the second time, and now... ugh.
On VS2012 and VS2010 both the marked line will flag an error without a cast. clang will compile it with a warning in C, but allow it (which I found surprising). Given, you do have to really step out of your happy place to break it, but it is still none-the-less broken.
The rest of this is a diatribe on identifying pointer types, their constness, and what is equivalent to what.
Long Diatribe on Pointers And Const
The warning is because char ** and const char ** are not equivalent (duh). To be correct, you could fix the prototype (callee), or fix the caller (by loading an array of const char * and passing that). But can you safely typecast the first to the second? Hmmm....
Remember, by the standard const goes to the item immediately to its left. Declaring it on the most-left of a data type is a nicety that the language supports, but often introduces confusion or problems. As a rule-of-thumb, if const appears on the far-left of a decl immediately before the type, it applies to the data type; not the subsequent pointer (if any). When it appears to the right of anything it applies to the immediate-left decl-part, be it a data type part or a pointer part, but no matter what it only applies to a single part.
A plethora of samples follows:
No Indirection:
const char ch; // const character. must be initialized.
char const ch; // same as above
Single-Indirection:
char *p; // p is mutable, *p is mutable
const char *p; // p is mutable, *p is const
char const *p; // same as above.
char *const p; // p is const, *p is mutable, must be initialized.
char const *const p; // p is const, *p is const, must be initialized.
Double Indirection:
char **p; // ptr-to-ptr-to-char
// p, *p, and **p are ALL mutable
const char **p; // ptr-to-ptr-to-const-char
// p and *p are mutable, **p is const
char const **p; // same as above
char *const *p; // ptr-to-const-ptr-to-char
// p is mutable, *p is const, **p is mutable.
char **const p; // const-ptr-to-ptr-to-char
// p is const, *p is mutable, **p is mutable.
// must be initialized.
const char **const p; // const-ptr-to-ptr-to-const-char
// p is const, *p is mutable, **p is const.
// must be initialized.
char const **const p; // same as above
char const *const *p; // ptr-to-const-ptr-to-const-char
// p is mutable, *p is const, **p is const.
const char *const *p; // same as above.
char *const *const p; // const-ptr-to-const-ptr-to-char
// p is const, *p is const, **p is mutable.
// must be initialized.
And of course who can leave home without...
char const *const *const p; // const-ptr-to-const-ptr-to-const-char
// everything is const.
// must be initialized.
const char *const *const p; // same as above
So how does this affect your question? When compiling that code in C, without a cast you'll get a compiler warning (or error if compiling with -Werror). When compiling in C++, you'll just plain error because the parameter signature doesn't match. But why?
Because these have no direct equivalence:
const char **p; // ptr-to-ptr-to-const-char
// p and *p are mutable **p is const
char **p; // ptr-to-ptr-to-char
// p, *p, and **p are all mutable
When compiling with clang, the exact warning in C is given as:
main.c:15:9: Passing
char **to parameter of typeconst char **discards qualifiers in nested pointer types.
VS2010 and VS2012 both, on the other hand, toss an error:
error C2440: 'initializing' : cannot convert from 'char **' to 'const char **'
It seems odd, but VS is actually more correct (wonders never cease).
And that makes perfect sense. Nestled down in the type declaration is the fact that the first of these does not allow modification to the final data, the second does. From above we know that char ** and const char ** (aka. char const **), are not the same. At the bottom of one is a pointer to a const char, while the other has a pointer to char.
edit: I even answered the wrong question. My answer is completely irrelevant! Ignore me please.
edit 2: after the gentleman question asker clarifies his question, it turns out that my answer is in fact relevant. C'est la vie.
This is a fun bit of C, which makes sense if you think hard enough about it.
Basically, the conversion:
char** ptr;
const char** const_ptr;
const_ptr = ptr; // <-- BAD!
is not allowed.
Why, you might ask? "I'm making things more const! This is obviously a good thing!"
Well, think about this. If that were allowed, then:
const char c = 'A';
char* ptr;
const char** const_ptr = &ptr; // <-- ILLEGAL, but what if this were legal?
*const_ptr = &c;
*ptr = 'B'; // <- you just assigned to "const char c" above.
BAM you're dead. So... no :-)