> 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).
Received on Sat Oct 21 14:36:15 2006