[GRASS5] Summary of significant compiler warnings

Even without any -W switches, compilation generates a number of
warnings. I fixed the more straightforward ones recently; what follows
is a list of ones which need more consideration, preferably from someone
who is familiar with the code.

lib/db/dbmi_base
dirent.c: In function `cmp_dirent':
dirent.c:144: warning: passing arg 1 of `db_get_string' discards qualifiers from pointer target type
dirent.c:144: warning: passing arg 1 of `db_get_string' discards qualifiers from pointer target type

I suspect that db_get_string() should probably take a "const dbString *"
argument. If it doesn't, it can't be used in the qsort() comparison
routine, which isn't allowed to modify the data which it is passed.

lib/image

Lots of warnings, due to implicit typecasts. The code makes a lot of
assumptions about the layout of the IMAGE structure, and will break on
any platform where the layout of the IMAGE structure doesn't match the
code's expectations.

lib/g3d
g3ddefaults.c: In function `G3d_initDefaults':
g3ddefaults.c:592: warning: assignment from incompatible pointer type

This is due to G3d_fatalError() being assigned to g3d_error_fun in spite
of the types being incompatible. g3d_error_fun has type:

  void (*g3d_error_fun)();

while G3d_fatalError() has type:

  extern void G3d_fatalError (/* msg */ char *, ...);

Furthermore, G3d_fatalError() calls G_fatal_error() with the message
(after substitutions) as its first argument. This will fail if the
substitued string contains any % characters.

lib/ogsf

Many warnings due to gsd_getwindow() expecting pointers to int/double
but the code which uses it passing pointers to GLint/GLdouble. Also, in
spite of its protoype, gsd_getwindow() actually requires pointers to
GLint/GLdouble because it is passing the pointers directly to
glGetIntegerv() and glGetDoublev().

At first I thought that the incorrect prototype was due to not wanting
to have expose OpenGL types in the public API, but ogsf_proto.h uses
OpenGL types in other places.

db/drivers/ogr
describe.c: In function `describe_table':
describe.c:85: warning: assignment discards qualifiers from pointer target type
describe.c:123: warning: assignment discards qualifiers from pointer target type

Both due to:

  fieldName = OGR_Fld_GetNameRef( hFieldDefn );

OGR_Fld_GetNameRef() returns a "const char *", but fieldName is
"char *". Simply changing the type of fieldName won't work because it is
passed to db_set_column_name(), which requires a "char *". This could be
a bug (if the string really does need to be mutable), but it seems more
likely that the "const" was omitted from db_set_column_name() (and
several other places in the DB API, AFAICT).

db/base
describe.c: In function `parse_command_line':
describe.c:119: warning: assignment makes pointer from integer without a cast

    parms.printcolnames = cols->answer;

parms.printcolnames is a char *, but cols->answer is a char (cols is a
"struct Flag *"). I think that this field is a boolean, but parms is
exported from describe.c, so I can't easily be sure.

raster/r.le/r.le.pixel
cellclip.c: In function `cell_clip_drv':
cellclip.c:82: warning: passing arg 2 of `cell_clip' from incompatible pointer type
cellclip.c:129: warning: passing arg 2 of `center_is_not_null' from incompatible pointer type

Both due to passing a "char **" to a function which expects a "DCELL **".
On some (relatively obscure) platforms, this is a bug in itself, regardless of
whether or not the "char **" actually points to DCELL data.

raster/r.resamp.rst
main.c:498: warning: passing arg 43 of `IL_init_params_2d' makes integer from pointer without a cast

Two problems here. The warning is due to using NULL where an integer is
expected; I'll fix that.

The other problem is the fact that the protoype has 43 arguments. While
this isn't a bug (at least, C99 allows up to 127 arguments; I don't know
about C89), it is bad design.

The first time I saw this I just skipped it rather than try to figure
out which argument is number 43. It's only because I counted the total
number of parameters that I discovered that it's the last one.

This function should be broken into several smaller functions so that if
an error or warning refers to e.g. "arg 27", you don't have to manually
count through argument list.

raster/simwe/simlib
output.c: In function `output_data':
output.c:556: warning: comparison between pointer and integer

   if (disch == 1)

disch is treated as a pointer elsewhere in the code. I haven't tracked
it down beyond that, as disch is defined in another file.

raster/simwe/r.sim.water
main.c: In function `main':
main.c:289: warning: assignment makes pointer from integer without a cast

  mscale=flag.mscale->answer;

The answer field of "struct Flag" is a char, not a char*. Again, mscale
is defined in another file.

raster/simwe/r.sim.sediment
main.c: In function `main':
main.c:281: warning: assignment makes pointer from integer without a cast
main.c:282: warning: assignment makes pointer from integer without a cast

  mscale=flag.mscale->answer;
  tserie=flag.tserie->answer;

Both mscale and serie are defined in another file.

raster3d/r3.out.v5d
main.c: In function `convert':
main.c:256: warning: passing arg 7 of `v5dCreate' from incompatible pointer type

Awkward. The argument VarName is defined as:

   char VarName[MAXVARS][10]; /* names of variables */

but the parameter is declared as:

   const char varname[MAXVARS][10],

One rather annoying feature of the C standard is that const arrays are
incompatible with mutable arrays. I don't know of any architectures
where this matters, or even /why/ this is the case.

The solution is probably to remove the const from v5dCreate. BTW, both
r3.in.v5d and r3.out.v5d contain clones of v5d.[ch].

vector/v.surf.rst
main.c: In function `main':
main.c:641: warning: passing arg 41 of `IL_init_params_2d' from incompatible pointer type

The argument (devi) is a char* but the parameter is a FILE*. This
appears to be a bug, although the RST library appears to treat it as a
boolean (i.e. it only cares whether or not it is NULL).

The other 120 warnings all relate to NVIZ. 26 of those correspond to
defining __STDC__ on the command-line, while 21 are duplicates of:

interface.h:363: warning: `struct Map_info' declared inside parameter list
interface.h:363: warning: its scope is only this definition or declaration, which is probably not what you want

The other 73 consist of:

count file message

28 <multiple> passing arg 2 of `Tcl_Merge' from incompatible pointer type
12 <multiple> passing arg 4 of `Tcl_SplitList' from incompatible pointer type
7 site_attr_commands.c passing arg 1 of `G_sites_close' from incompatible pointer type
2 togl.c passing arg 3 of `Tcl_CreateCommand' from incompatible pointer type
1 togl.c passing arg 5 of `Tk_ConfigureWidget' from incompatible pointer type
21 <multiple> assignment discards qualifiers from pointer target type
1 togl_flythrough.c initialization discards qualifiers from pointer target type

--
Glynn Clements <glynn@gclements.plus.com>

Glynn Clements wrote:

Even without any -W switches, compilation generates a number of
warnings. I fixed the more straightforward ones recently; what follows
is a list of ones which need more consideration, preferably from someone
who is familiar with the code.

lib/db/dbmi_base
dirent.c: In function `cmp_dirent':
dirent.c:144: warning: passing arg 1 of `db_get_string' discards qualifiers from pointer target type

I suspect that db_get_string() should probably take a "const dbString *"
argument. If it doesn't, it can't be used in the qsort() comparison
routine, which isn't allowed to modify the data which it is passed.

lib/image

Lots of warnings, due to implicit typecasts. The code makes a lot of
assumptions about the layout of the IMAGE structure, and will break on
any platform where the layout of the IMAGE structure doesn't match the
code's expectations.

lib/g3d
g3ddefaults.c: In function `G3d_initDefaults':
g3ddefaults.c:592: warning: assignment from incompatible pointer type

This is due to G3d_fatalError() being assigned to g3d_error_fun in spite
of the types being incompatible. g3d_error_fun has type:

void (*g3d_error_fun)();

while G3d_fatalError() has type:

extern void G3d_fatalError (/* msg */ char *, ...);

Furthermore, G3d_fatalError() calls G_fatal_error() with the message
(after substitutions) as its first argument. This will fail if the
substitued string contains any % characters.

lib/ogsf

Many warnings due to gsd_getwindow() expecting pointers to int/double
but the code which uses it passing pointers to GLint/GLdouble. Also, in
spite of its protoype, gsd_getwindow() actually requires pointers to
GLint/GLdouble because it is passing the pointers directly to
glGetIntegerv() and glGetDoublev().

At first I thought that the incorrect prototype was due to not wanting
to have expose OpenGL types in the public API, but ogsf_proto.h uses
OpenGL types in other places.

db/drivers/ogr
describe.c: In function `describe_table':
describe.c:85: warning: assignment discards qualifiers from pointer target type
describe.c:123: warning: assignment discards qualifiers from pointer target type

Both due to:

fieldName = OGR_Fld_GetNameRef( hFieldDefn );

OGR_Fld_GetNameRef() returns a "const char *", but fieldName is
"char *". Simply changing the type of fieldName won't work because it is
passed to db_set_column_name(), which requires a "char *". This could be
a bug (if the string really does need to be mutable), but it seems more
likely that the "const" was omitted from db_set_column_name() (and
several other places in the DB API, AFAICT).

db/base
describe.c: In function `parse_command_line':
describe.c:119: warning: assignment makes pointer from integer without a cast

   parms.printcolnames = cols->answer;

parms.printcolnames is a char *, but cols->answer is a char (cols is a
"struct Flag *"). I think that this field is a boolean, but parms is
exported from describe.c, so I can't easily be sure.

raster/r.le/r.le.pixel
cellclip.c: In function `cell_clip_drv':
cellclip.c:82: warning: passing arg 2 of `cell_clip' from incompatible pointer type
cellclip.c:129: warning: passing arg 2 of `center_is_not_null' from incompatible pointer type

Both due to passing a "char **" to a function which expects a "DCELL **".
On some (relatively obscure) platforms, this is a bug in itself, regardless of
whether or not the "char **" actually points to DCELL data.

raster/r.resamp.rst
main.c:498: warning: passing arg 43 of `IL_init_params_2d' makes integer from pointer without a cast

Two problems here. The warning is due to using NULL where an integer is
expected; I'll fix that.

The other problem is the fact that the protoype has 43 arguments. While
this isn't a bug (at least, C99 allows up to 127 arguments; I don't know
about C89), it is bad design.

The first time I saw this I just skipped it rather than try to figure
out which argument is number 43. It's only because I counted the total
number of parameters that I discovered that it's the last one.

This function should be broken into several smaller functions so that if
an error or warning refers to e.g. "arg 27", you don't have to manually
count through argument list.

raster/simwe/simlib
output.c: In function `output_data':
output.c:556: warning: comparison between pointer and integer

  if (disch == 1)

disch is treated as a pointer elsewhere in the code. I haven't tracked
it down beyond that, as disch is defined in another file.

raster/simwe/r.sim.water
main.c: In function `main':
main.c:289: warning: assignment makes pointer from integer without a cast

mscale=flag.mscale->answer;

The answer field of "struct Flag" is a char, not a char*. Again, mscale
is defined in another file.

raster/simwe/r.sim.sediment
main.c: In function `main':
main.c:281: warning: assignment makes pointer from integer without a cast
main.c:282: warning: assignment makes pointer from integer without a cast

mscale=flag.mscale->answer;
tserie=flag.tserie->answer;

Both mscale and serie are defined in another file.

raster3d/r3.out.v5d
main.c: In function `convert':
main.c:256: warning: passing arg 7 of `v5dCreate' from incompatible pointer type

Awkward. The argument VarName is defined as:

  char VarName[MAXVARS][10]; /* names of variables */

but the parameter is declared as:

  const char varname[MAXVARS][10],

One rather annoying feature of the C standard is that const arrays are
incompatible with mutable arrays. I don't know of any architectures
where this matters, or even /why/ this is the case.

The solution is probably to remove the const from v5dCreate. BTW, both
r3.in.v5d and r3.out.v5d contain clones of v5d.[ch].

vector/v.surf.rst
main.c: In function `main':
main.c:641: warning: passing arg 41 of `IL_init_params_2d' from incompatible pointer type

The argument (devi) is a char* but the parameter is a FILE*. This
appears to be a bug, although the RST library appears to treat it as a
boolean (i.e. it only cares whether or not it is NULL).

The other 120 warnings all relate to NVIZ. 26 of those correspond to
defining __STDC__ on the command-line, while 21 are duplicates of:

interface.h:363: warning: `struct Map_info' declared inside parameter list
interface.h:363: warning: its scope is only this definition or declaration, which is probably not what you want

The other 73 consist of:

count file message

28 <multiple> passing arg 2 of `Tcl_Merge' from incompatible pointer type
12 <multiple> passing arg 4 of `Tcl_SplitList' from incompatible pointer type
7 site_attr_commands.c passing arg 1 of `G_sites_close' from incompatible pointer type
2 togl.c passing arg 3 of `Tcl_CreateCommand' from incompatible pointer type
1 togl.c passing arg 5 of `Tk_ConfigureWidget' from incompatible pointer type
21 <multiple> assignment discards qualifiers from pointer target type
1 togl_flythrough.c initialization discards qualifiers from pointer target type

So is a warning like:
popen.c: In function ‘G_popen’:
popen.c:64: warning: missing sentinel in function call

not significant? Sorry, I'm not a c programmer, so I don't know what to report and what to ignore.

Michael

Michael Rensing wrote:

So is a warning like:
popen.c: In function ‘G_popen’:
popen.c:64: warning: missing sentinel in function call

not significant? Sorry, I'm not a c programmer, so I don't know what to
report and what to ignore.

I had to look this one up on google. It appears to be new in gcc 4.x,
which explains why I've never seen it.

Basically, it's warning that the last argument should be a null
pointer, when it's actually the integer 0.

That particular case is significant; it could cause problems on 64-bit
platforms, where a pointer is larger than an int.

Warnings which are generated even when no -W switches are used are
significant, as they usually indicate implementation-dependent
behaviour.

--
Glynn Clements <glynn@gclements.plus.com>