[GRASS5] GRASS 5.1 v.in.ascii bug

[Glynn Clements]

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 at virgin.net>