Hello
I was trying to run the GRASS 5.1 tour script and encountered a problem
with v.in.ascii. The imported maps were empty apart from the header
metadata lines. I looked at the source code and the problem seems to be
that in vector/v.in.ascii/a2b.c the variable n_points is referenced without
being initialised to a value. On line 49 there is
if (!n_points)
continue;
If I comment out those two lines it seems to work fine. This seems to be
quite a major bug. Probably that is not the correct solution though.
Out of interest I tried compiling the same module on Linux using gcc and
sure enough the warning came up
a2b.c:21: warning: `n_points' might be used uninitialized in this function
All the new modules seem to generate so many warnings. If we could get rid
of them it would probably fix a lot of the bugs as well.
Paul
On Wednesday 07 May 2003 05:40 pm, Paul Kelly wrote:
Hello
I was trying to run the GRASS 5.1 tour script and encountered a problem
with v.in.ascii. The imported maps were empty apart from the header
metadata lines. I looked at the source code and the problem seems to be
that in vector/v.in.ascii/a2b.c the variable n_points is referenced without
being initialised to a value. On line 49 there is
if (!n_points)
continue;
If I comment out those two lines it seems to work fine. This seems to be
quite a major bug. Probably that is not the correct solution though.
This was normal bug, I think that remove those lines is correct and I have
done that.
Out of interest I tried compiling the same module on Linux using gcc and
sure enough the warning came up
a2b.c:21: warning: `n_points' might be used uninitialized in this function
All the new modules seem to generate so many warnings. If we could get rid
of them it would probably fix a lot of the bugs as well.
I was not using -Wall first, now (circa one year) I am compiling with
-Wall and I aim to make a code which compiles without warnings.
In all vector/* modules, which may be considered as new,
I have got only 13 warnings (12 uninitialized, 1 unused).
Did you get more (many) warnings in vector/* modules or in
others? Did you get more warnings on IRIX?
Some of 'uninitialized' may be bugs and when I get this warning
(in new code) I usually try to fix it. However, sometimes I don't know
how to (cleanly) avoid this warning. For example on:
int main( int argc, char **argv ) {
int i, a, x;
a = rand();
if ( a ) {
i = 1;
x = 0;
} else {
i = 0;
}
if ( i ) printf ("%d\n", x);
exit (0);
}
gcc -Wall prints: warning: `x' might be used uninitialized in this function
IMHO it may not be used uninitialized. Am I missing something?
Please explain this to me.
Simply add x=0; at the beginning to avoid this warning doesn't
seem to be correct.
Radim
Radim Blazek wrote:
Some of 'uninitialized' may be bugs and when I get this warning
(in new code) I usually try to fix it. However, sometimes I don't know
how to (cleanly) avoid this warning. For example on:
int main( int argc, char **argv ) {
int i, a, x;
a = rand();
if ( a ) {
i = 1;
x = 0;
} else {
i = 0;
}
if ( i ) printf ("%d\n", x);
exit (0);
}
gcc -Wall prints: warning: `x' might be used uninitialized in this function
IMHO it may not be used uninitialized. Am I missing something?
As the error says, it *might* be used uninitialised. gcc doesn't
perform exhaustive analysis of the program logic. It just keeps track
of whether a variable is known to have been initialised in a given
context (in the sense of yes/no/maybe; not in the sense of
yes/no/only-if-i-is-non-zero).
--
Glynn Clements <glynn.clements@virgin.net>
On Thu, 8 May 2003, Radim Blazek wrote:
On Wednesday 07 May 2003 05:40 pm, Paul Kelly wrote:
> Out of interest I tried compiling the same module on Linux using gcc and
> sure enough the warning came up
> a2b.c:21: warning: `n_points' might be used uninitialized in this function
>
> All the new modules seem to generate so many warnings. If we could get rid
> of them it would probably fix a lot of the bugs as well.
I was not using -Wall first, now (circa one year) I am compiling with
-Wall and I aim to make a code which compiles without warnings.
In all vector/* modules, which may be considered as new,
I have got only 13 warnings (12 uninitialized, 1 unused).
Did you get more (many) warnings in vector/* modules or in
others? Did you get more warnings on IRIX?
With gcc on Linux I can confirm I got the same errors as you but
unfortunately on IRIX there were many more:
compiler errors:
21 missing function prototypes
linker errors:
1 ld-defined internal symbol defined by a program
48 multiply-defined symbols
64 library not used for resolving any symbol
I really don't know how to catch these on Linux. I don't think -ansi
helps. The missing function prototypes can be a source of bugs as I
think the SGI cc compiler will assume the return type is an int if there
is no prototype. I don't know how gcc can get by without the function
prototypes though. Does it just assume the return type is the same as the
variable it is being assigned to?
The multiply-defined symbols come from variables in header files not being
declared as extern. I fixed one in lib/vector/rtree that was causing
several screenfuls of warnings for every module that used the vector
library but there are still others there.
Paul
Paul Kelly wrote:
> > Out of interest I tried compiling the same module on Linux using gcc and
> > sure enough the warning came up
> > a2b.c:21: warning: `n_points' might be used uninitialized in this function
> >
> > All the new modules seem to generate so many warnings. If we could get rid
> > of them it would probably fix a lot of the bugs as well.
>
> I was not using -Wall first, now (circa one year) I am compiling with
> -Wall and I aim to make a code which compiles without warnings.
> In all vector/* modules, which may be considered as new,
> I have got only 13 warnings (12 uninitialized, 1 unused).
> Did you get more (many) warnings in vector/* modules or in
> others? Did you get more warnings on IRIX?
With gcc on Linux I can confirm I got the same errors as you but
unfortunately on IRIX there were many more:
compiler errors:
21 missing function prototypes
linker errors:
1 ld-defined internal symbol defined by a program
48 multiply-defined symbols
64 library not used for resolving any symbol
I really don't know how to catch these on Linux.
The gcc switch -Wimplicit-function-declaration (implied by -Wall) should
report missing prototypes (use -Werror-implicit-function-declaration to
make it an error rather than a warning).
The linker switch --warn-common (e.g. LDFLAGS='-Wl,--warn-common') might
be useful for catching multiply-defined symbols.
I don't think -ansi
helps. The missing function prototypes can be a source of bugs as I
think the SGI cc compiler will assume the return type is an int if there
is no prototype. I don't know how gcc can get by without the function
prototypes though. Does it just assume the return type is the same as the
variable it is being assigned to?
No, it assumes that the return type is "int"; that behaviour is
dictated by both ANSI C and K&R. However, a missing prototype should
only result in a warning, not an error. OTOH, missing protypes should
definitely be fixed.
You might legitimately get different results between Linux and IRIX.
Sometimes the necessary header gets included by coincidence; i.e. one
of the headers which is explicitly included will in turn include a
header which turns out to be necessary.
Source files *should* explicitly include the appropriate headers for
any symbols which they use directly; e.g. any file which uses "FILE*",
stdio functions, or NULL should explicitly include stdio.h, even
though it gets indirectly included via gis.h. However, there isn't any
practical way to check this.
--
Glynn Clements <glynn.clements@virgin.net>
On Thu, May 08, 2003 at 06:08:05PM +0100, Glynn Clements wrote:
[...]
The gcc switch -Wimplicit-function-declaration (implied by -Wall) should
report missing prototypes (use -Werror-implicit-function-declaration to
make it an error rather than a warning).
Trying this, I got:
gcc -g -Wall -ansi -Werror-implicit-function-declaration -Wall
-I/ssi0/ssi/neteler/grass51/include
-I/ssi0/ssi/neteler/grass51/dist.i686-pc-linux-gnu/include
-I/ssi0/ssi/neteler/grass51/include
-I/ssi0/ssi/neteler/grass51/dist.i686-pc-linux-gnu/include \
-o OBJ.i686-pc-linux-gnu/sleep.o -c sleep.c
sleep.c: In function 'time_ltp':
sleep.c:64: storage size of 'tzone' isn't known
sleep.c:64: warning: unused variable zone'
sleep.c: At top level:
/ssi0/ssi/neteler/grass51/include/gis.h:36: warning: aRASS_copyright'
defined but not used
make[2]: *** [OBJ.i686-pc-linux-gnu/sleep.o] Error 1
make[2]: Leaving directory /hardmnt/thuille0/ssi/grass51/lib/gis'
make[1]: *** [subdirs] Error 1
Is below a reasonable path?
cvs diff -u sleep.c
Index: sleep.c
RCS file: /grassrepository/grass/src/libes/gis/sleep.c,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 sleep.c
--- sleep.c 29 Dec 1999 15:10:31 -0000 1.1.1.1
+++ sleep.c 9 May 2003 09:44:30 -0000
@@ -61,9 +61,8 @@
int time_ltp( double *time)
{
struct timeval tstruct;
- struct timezone tzone;
- gettimeofday (&tstruct, &tzone);
+ gettimeofday (&tstruct, (struct timezone *)NULL);
*time = tstruct.tv_sec + tstruct.tv_usec / 1000000.0;
return(0);
}
-----------------------------
The next error appears in lib/image/open.c which I don't know to fix:
gcc -g -Wall -ansi -Werror-implicit-function-declaration -Wall
-I/ssi0/ssi/neteler/grass51/include
-I/ssi0/ssi/neteler/grass51/dist.i686-pc-linux-gnu/include
-I/ssi0/ssi/neteler/grass51/include
-I/ssi0/ssi/neteler/grass51/dist.i686-pc-linux-gnu/include \
-o OBJ.i686-pc-linux-gnu/open.o -c open.c
open.c:29: parse error before 'getshort'
[...]
make[2]: *** [OBJ.i686-pc-linux-gnu/open.o] Error 1
make[2]: Leaving directory /hardmnt/thuille0/ssi/grass51/lib/image'
make[1]: *** [subdirs] Error 1
Maybe someone more C expert than me could spend some time and compile
5.1 with the suggested -Werror-implicit-function-declaration flag...
Markus
Markus Neteler wrote:
> The gcc switch -Wimplicit-function-declaration (implied by -Wall) should
> report missing prototypes (use -Werror-implicit-function-declaration to
> make it an error rather than a warning).
Trying this, I got:
Note: both of these errors are due to the use of -ansi, not the
-Werror-implicit-function-declaration switch.
This issue was described in more detail here:
From: Glynn Clements <glynn.clements@virgin.net>
Subject: Re: [GRASS5] r.sun bug
Date: Mon, 24 Feb 2003 18:53:25 +0000
Message-ID: <15962.27173.280123.968664@cerise.nosuchdomain.co.uk>
gcc -g -Wall -ansi -Werror-implicit-function-declaration -Wall
-I/ssi0/ssi/neteler/grass51/include
-I/ssi0/ssi/neteler/grass51/dist.i686-pc-linux-gnu/include
-I/ssi0/ssi/neteler/grass51/include
-I/ssi0/ssi/neteler/grass51/dist.i686-pc-linux-gnu/include \
-o OBJ.i686-pc-linux-gnu/sleep.o -c sleep.c
sleep.c: In function 'time_ltp':
sleep.c:64: storage size of 'tzone' isn't known
sleep.c:64: warning: unused variable zone'
sleep.c: At top level:
/ssi0/ssi/neteler/grass51/include/gis.h:36: warning: aRASS_copyright'
defined but not used
make[2]: *** [OBJ.i686-pc-linux-gnu/sleep.o] Error 1
make[2]: Leaving directory /hardmnt/thuille0/ssi/grass51/lib/gis'
make[1]: *** [subdirs] Error 1
Is below a reasonable path?
Yes; except, you don't need an explicit type cast for NULL.
The next error appears in lib/image/open.c which I don't know to fix:
gcc -g -Wall -ansi -Werror-implicit-function-declaration -Wall
-I/ssi0/ssi/neteler/grass51/include
-I/ssi0/ssi/neteler/grass51/dist.i686-pc-linux-gnu/include
-I/ssi0/ssi/neteler/grass51/include
-I/ssi0/ssi/neteler/grass51/dist.i686-pc-linux-gnu/include \
-o OBJ.i686-pc-linux-gnu/open.o -c open.c
open.c:29: parse error before 'getshort'
That file relies upon BSD extensions, so you need to use
-D_BSD_SOURCE=1 when using -ansi (when not using -ansi, gcc enables
most of the extension macros).
--
Glynn Clements <glynn.clements@virgin.net>