Change request:
Version:
gcc (GCC) 3.3.5 (Debian 1:3.3.5-8)
Opinion:
The default set of warnings for gcc is not sane, and
eventually causes lower quality code. The incompatible
pointer type warning, when applied to void* checks
is guilty of this.
In my opinion the current set of compiler warnings is not
helping the developer, but is hampering her.
Code sample:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#define _mymalloc(p,s) mymalloc((void**)(p),(s))
int mymalloc(void **pPointer, size_t size)
{
*pPointer = malloc(size);
return (NULL == *pPointer) ? -1 : 0;
}
int main(int argc, char **pArgv)
{
char *pString;
// warning: passing arg 1 of `mymalloc' from incompatible pointer type
// call is GOOD
if (!mymalloc(&pString, 255)) { free(pString); }
// warning: passing arg 1 of `mymalloc' from incompatible pointer type
// call is BAD
if (!mymalloc(pString, 255)) { free(pString); }
// call is GOOD, no warning
if (!_mymalloc(&pString, 255)) { free(pString); }
// call is BAD, no warning
if (!_mymalloc(pString, 255)) { free(pString); }
return 0;
}
Commandline:
gcc -o sample sample.c
Description:
Above code yields compile warnings with the default set of
warnings included in gcc.
It's my opinion the gcc compiler should relax this check,
and accept ANY** for void**, and warn about all other cases.
The current behaviour should be optional for those who
need it, and the warning message should be changed to
allow distinction between the two different cases.
Rationale 1:
The mymalloc(&pString, 255) call in above sample is valid
and good, and should not yield a warning.
For valid calls like this, getting rid of the warning requires
either explicit casts, or disabling the warning.
Explicit casts are dangerous in this case, and yield lower-
quality code with reduced maintainability and readability.
There is from a developer's point of view no added benefit
of changing the call and adding a cast.
A quick way of getting rid of the warning is wrapping in
a macro (see sample). However this will yield lower quality
code because also the bad calls are not picked up
by the compiler anymore.
Disabling the warning is not an option when working
in an environment where release code must compile
warning-free with -Wall.
Rationale 2:
The gcc compiler does not make a distinction between
the good mymalloc(&pString, 255) and the bad
mymalloc(pString, 255).
When compiling a large project (this request was caused
by a re-compile of code with gcc-3 of a 200k-line project)
the number of generated warnings like these is vast,
and the likelyhood of a bad call going undetected is
large.
The current compiler output is in my opinion not
acceptable. It should be possible to make a distinction
between the good and the bad case.
Rationale 3:
Working safely with the gcc compiler is time-consuming
now, provided warning free compilation with the default
warning set is a requirement for delivery.
The safe process now is write the code without casts,
compile, check out all these warnings manually and
explicity cast the cases that are good, and recompile.
This is time-consuming and not necessary.
Comparison:
When compiling above code on three different compilers,
results are as follows.
GCC 3.3.5:
sample.c:20: warning:
passing arg 1 of `mymalloc' from incompatible pointer type
sample.c:24: warning:
passing arg 1 of `mymalloc' from incompatible pointer type
(total: 0 errors, 2 warnings)
Microsoft C Compiler:
sample.c(24) : warning C4047: 'function' : 'void ** '
differs in levels of indirection from 'char *'
(total: 0 errors, 1 warning)
GreenHills Software - MULTI Compiler for Mips
sample.c, line 24: warning:
Illegal combination of two pointers, when casting char* to void**
(total: 0 errors, 1 warning)
--
Summary: warning: passing arg 1 of `mymalloc' from incompatible
pointer type
Product: gcc
Version: 3.3.5
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pbijdens at storagelabs dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20422
