[GRASS5] List of compile warnings

[Glynn Clements]

Markus Neteler wrote:

> using the CRAY compiler (maybe the -Wall would do the same) I
> have generated a list of compile warnings in CVS:
> 
> cvs up documents/compile_warnings.log
> 
> Originally it contained 354 warnings, I have fixed a lot (and thrown out the
> qsort warnings) and would leave the others for you :-) (142 to go).
> 
> A few problems a looking severe.

Mostly either qsort() or signed/unsigned char* mismatch, with a couple
of other function pointer mismatches (basically the same issue as for
qsort). As for the rest:

* src/libes/vask/V_tty.c:

This is using a function returning "int" as a signal handler; on
GNU/Linux (at least), signal handlers return void. This could be an
issue on certain platforms (specifically, if a return value is pushed
onto the stack, or stored in a register which is assumed to be
unmodified by the call).

Aside: is use of signal() a good idea? Is it meant to be the BSD or
SysV version? Should sigaction() be used instead?

* src/misc/m.kappa/cmd/readin_data.c:

This treats "mat" as "int**", but mkappa.h indicates that it is
"long**". The second G_malloc needs to allocate "ncat * sizeof (long)"
bytes, and the fscanf should be using "%ld", not "%d". This will be a
problem if sizeof(int) != sizeof(long).

* src/display/devices/lib/socket.new/SWITCHER.c:

The explicit cast to (unsigned int *) is redundant; the parameter is
an "int*" like the (uncast) argument.

* src/ps.map/ps.map/cmd/vect.c:

    l   = LENGTH ( dx, dy );
    if ( l == 0){
    }
    *x  = 5 / 0;
    *x  = dx/l;
    *y  = dy/l;

WTF?

Fix: choice of (0,0), (NaN,NaN), raise(SIGFPE), something else?

* src/raster/r.infer/cmd/infer.h:

Redefines "TRUE" and "FALSE", which are already defined in gis.h. 
Harmless, but should probably be removed.

* src/raster/r.surf.idw/cmd/main.c:

Using comments to disable code containing comments:

    /*nbr_head->distance = maxdist;
    nbr_head->searchptr = &(nbr_head->Mptr);      /* see replace_neighbor */

Fix: don't use comments to disable code; use "#ifdef notdef ... #endif".

Also, it's not immediately clear as to whether both lines were meant
to be disabled, or just the first one.

* src/sites/cdhc/as181.c:

These are real errors; pointer to double being passed where a double
is expected (eps) and vice-versa (w, p).

* src/sites/s.to.rast/main.c:

Compiler moaning about valid code:

		default: /* Should never happen */
	    }

Workaround: add a "break".

* src/libes/libimage/open.c:

cvtshorts() expects "register unsigned short buffer[]" (which means
what, exactly? an array of register variables?) but cvtimage() is
passing "register long buffer[]". It appears that "buffer" is actually
mixed shorts/longs (I think that, by "long", the author means "32-bit
integer"). I still think that this is a real error, though.

Aside: someone should just remove all references to "register" from
this code; it doesn't seem to make much sense in the context of
function parameters.

* src.contrib/SDTS/mapdev/v.out.sdts/spatial_ref.c:

Takes a parameter of type "struct Map_info" (defined in
"d.what.vect/cmd/what.h", which it doesn't include). It never actually
uses this parameter, though.

* src.contrib/SDTS/mapdev/v.in.sdts/<something>:

Some file (the message doesn't say) includes the header
src.contrib/SDTS/libes/fips123/f123inc/stc123.h, which defines
"MAXINT" as "32767L". However, GNU libc defines this (in values.h) as
an alias for "INT_MAX".

Fix: change the name, or use "SHRT_MAX" (from limits.h).

-- 
Glynn Clements <glynn.clements at virgin.net>

---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'