[GRASS5] Summary of significant compiler warnings

[Michael Rensing]

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
>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