[Bug c/20422] warning: passing arg 1 of `mymalloc' from incompatible pointer type

["pbijdens at storagelabs dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From pbijdens at storagelabs dot com  2005-03-11 17:54 -------
Given that the default mode of the gcc compiler is pedantic, and accepting your
statement that the warning is standard-compliant. Also given that both cases
indeed violate the standard in the same way, I would like to suggest the
following analyses:

case 1: mymalloc(&pString, 255)
  -> we are passing char**, the function expects void**
  -> this means that the passed argument can (given correct typing
     and assignment) be dereferenced twice safely.
  -> from a developer's point of view this was the intended use.
     the warning can be ignored without grave side-effects for
     the resulting binary.

case 2: mymalloc(pString, 255)
  -> we are passing char*, the function expects void**
  -> this means there is no guarantee that the passed argument
     can be dereferenced twice, as required by the function
     header.
  -> from a developer's point of view, this is really
     wrong. ignoring this warning is no option. this is a bug,
     and the resulting binay would surely not function as
     expected.

Given above assumptions, both cases are worth a warning. Thing
is the second case is wrong in more ways than the first case, to
an extent where other compilers don't even bother warning for 
case 1. [accepting and understanding why gcc does warn here]

In case 1 the current warning sufficiently provides information: 
warning: passing arg 1 of `mymalloc' from incompatible pointer type

In case 2, the warning message from the Microsoft C compiler wins 
in the field of clarity by stating precicely what is wrong:

warning: passing arg 1 of `mymalloc': 
  'void **' differs in levels of indirection from 'char *'
 
My suggestion therefore would be to move towards a situation where
gcc distinguishes between those two cases in this same manner.

gcc would still warn about the incompliancy, but the probability
that a grave coding error remains in the code is lower. 

This gives the developer the choice to either ignore or suppress
the warning for case 1, without losing the warnings the really
severe case 2 in the process. With the current identical message
this unfortunately is impossible.

My opinion is that making such change leads to a win-win situation,
where gcc still enforces the standard, but the developer gets more
and better information.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20422