> Const doesn't change the type (storage size) of anything. So a > callee can *always* add a const qualifier to its parameters, as long > as it then keeps that promise to never modify the data.
This rule is too expansive. A parameter of type "pointer to const foo" is always compatible with an argument "pointer to foo"; the compiler is happy to do the implicit cast. However, a parameter of type "pointer to pointer to const foo" is not compatible with an argument of type "pointer to pointer to foo", because there can be no implicit cast of the middle pointer. If you don't believe me, try it and watch the compiler warning; I've sent an example before. Is a cast (implicit or explicit) really necessary if a const target doesn't change the storage features of the pointer? I'm not sure; that gets into the vagaries of just what an ANSI C implementation is or is not allowed to do differently with pointers to const foo. But practically speaking, we don't want callers of apr_initopts() to have to cast main()'s argv argument to avoid an incompatible type warning. (Having main() accept a "const char **argv" is just relegating the incompatible type faux pas to a place gcc won't currently warn about; it's still equally incorrect, and it's unreasonable for a library to require such a thing of its calling programs).