On Sun, 11 Apr 1999, Aidan Cully wrote:

> I was able to build a patch that fixed this, if it is, indeed, a bug..
> (I don't have any C-references, and I don't feel like looking through
> one even if I did.)  Can someone in the know please confirm with me
> that this behaviour _is_ a bug, and not defined C behaviour?  And that
> the attached patch (which I installed on my system to get kerberos
> building again) is correct?  In particular, I'm not sure that in all
> the instances that comptypes gets called that type1 is always the lhs
> and type2 is always the rhs..

The patch is not correct, since it removes the warning for 

   foo(const char **p) { }
   bar(char **p)
   {
      foo(p);
   }

The compiler is required to issue a warning for the above program
since (the argument below is taken from "Expert C Programming" by
Peter van Der Linden) the Constraints portion of section 6.3.2.2
(Function calls) of the ANSI C standard includes

   Each argument shall have a type such that its value may be
   assigned to an object with the unqualified version of the
   type of its corresponding parameter.

That is, argument passing is supposed to behave like assignment.

Section 6.3.16.1 (Simple assignment) has the following constraint

   both operands are pointers to qualified or unqualified versions
   of compatible types, and the type pointed to by the left has all
   the qualifiers of the type pointed to by the right;

This makes a call with a "char *" argument corresponding to a
"const char *" parameter legal.

The example portion of Section 6.1.2.5 (Types) states

   [..] the type designated "const float *" is not a qualified type --
   its type is "pointer to const-qualified float" and is a pointer
   to a qualified type.

So "const char **" denotes a pointer to an unqualified type. Its type
is "a pointer to a pointer to a qualified type". So "char **" and
"const char **" are both pointers to unqualified types that are not
the same type, so they are not compatible types, and the constraint
in Section 6.3.2.2 is violated, and a diagnostic message must be
produced.


To go back to the original program. The differences between it and
my example above are essentially only the typedef. Section 6.5.6
(Type definitions) says

   A typedef declaration does not introduce a new type, only a
   synonym for the type so specified.

so I think that the warning is required for the original program
too, but I'm not a language lawyer...

   /Krister