[GRASS5] snprintf and other compile errors on IRIX

[Glynn Clements]

Paul Kelly wrote:

> Hello
> I am running GRASS on two slightly out-of-date IRIX installations (6.2 and
> 6.4---nothing I can do about this!) and everytime I update our GRASS
> installation it seems even more modules are failing due to the snprintf
> function being used in them. I don't know that much about libraries but it
> is not in the standard ones that come with IRIX.

snprintf() isn't part of the original C89 specification. AFAICT, it
originated in BSD 4.4; it is part of the Single Unix Specification,
and C9X, but neither of those are sufficiently widespread to impose as
a requirement.

> This works fine but it is very tedious. I was wondering could the
> makefiles be changed for those modules that include snprintf in their code
> (list is below) to perhaps have another variable specifically referring to
> a 3rd party snprintf library at the end of the line after ($XDRLIB). [The
> snprintf library could even be included with GRASS to make it transparent
> to the end user], or else it could be specifed as an option to the
> configure script (probably a better idea if it only applies to very few
> platforms). Has anybody else had this problem and would it be as easy to
> fix as what I have suggested?

It's debatable whether we should actually be using snprintf() in any
case. Even on platforms which do implement it, there are differences
in the return value when the string is truncated.

And unless the code actually checks the return value, using snprintf()
instead of sprintf() may cause the program to behave incorrectly, but
without indicating an error. In that regard, using a third-party
snprintf() library may not provide a significant benefit over using a
stub which simply discards the size argument before calling
vsprintf().

Many of the cases where sprintf() is used should be probably replaced
with multiple calls to strcat(), using a dynamically allocated buffer
whose size is actually computed to ensure that no overflow occurs.

In any case, GRASS is absolutely littered with code which uses
fixed-size buffers without any bounds checking, so using snprintf() in
a few specific cases is a drop in the ocean.

> I found the following errors in addition to use of snprintf:
> 
> Compilation error in module: src/paint/p.vrml1.1 (ignored) 
> fixed by adding prototype void vrml_putline(int, FILE *, char *); at start
> of vrml.c

There are a number of problems with p.vrml1.1; I'll do a general
clean-up if it's going to stay.

> Compilation error in module: src/sites/s.hull (ignored) 
> has some // c++ style comments which my compiler rejects; just needed to
> change these to /* */

I'll fix that.

> Compilation error in module: src.contrib/GMSL/NVIZ2.2 (ignored)
> as well as the snprintf problem needed to remove newline between lines 232
> and 233 in NVIZ2.2/src/nviz_int.c

That's the broken string literal:

	fprintf(stderr, "ERROR: Number of elevation files does
	not match number of colors files\n");

right? I'll fix that.

> And the following modules had errors I couldn't fix
> 
> Compilation error in module: src/mapdev/v.in.mif (ignored) 
> 
> cc -I/indigo-disk2/grass/grass/src/include -g
> -I/indigo-disk2/grass/doom.ee.qub.ac.uk/include   -c lex.yy.c -o
> OBJ.mips-sgi-irix6.2/lex.yy.o
> cfe: Error: mif.l, line 572: Syntax Error
>         {blank} |
>         ------^
> make: *** [OBJ.mips-sgi-irix6.2/lex.yy.o] Error 1

I'm not sure what it's complaining about here; if you can find out
exactly what the error is, I'll commit the fix.

> Compilation error in module: src/raster/r.fill.dir (ignored) 
> 
> cc -I/indigo-disk2/grass/grass/src/include -g
> -I/indigo-disk2/grass/doom.ee.qub.ac.uk/include   -c wtrshed.c -o
> OBJ.mips-sgi-irix6.2/wtrshed.o
> cfe: Error: wtrshed.c, line 67: missing size for array 'dir'
>     struct whereandwhat dir[mxbuf];
>  -----------------------^
> cfe: Error: wtrshed.c, line 67: storage size for 'dir' isn't known
>     struct whereandwhat dir[mxbuf];
>  -----------------------^
> cfe: Error: wtrshed.c, line 67: Invalid constant expression.
>     struct whereandwhat dir[mxbuf];
>  ---------------------------^
> cfe: Error: wtrshed.c, line 68: missing size for array 'bas'
>     struct whereandwhat bas[mxbuf];
>  -----------------------^
> cfe: Error: wtrshed.c, line 68: storage size for 'bas' isn't known
>     struct whereandwhat bas[mxbuf];
>  -----------------------^
> make: *** [OBJ.mips-sgi-irix6.2/wtrshed.o] Error 1

I don't understand the "storage size" errors; "struct whereandwhat" is
defined at the top of that file. But the use of "mxbuf" is a gcc-ism,
which I'll fix (by using malloc()).

> Compilation error in module: src/raster/r.in.gdal (ignored) 
> 
> cc -L/indigo-disk2/grass/grass/src/libes/LIB.mips-sgi-irix6.2
> -L/indigo-disk2/grass/doom.ee.qub.ac.uk/lib -o
> /indigo-disk2/grass/grass/dist.mips-sgi-irix6.2/etc/bin/cmd/r.in.gdal
> OBJ.mips-sgi-irix6.2/main.o OBJ.mips-sgi-irix6.2/gbgetsymbol.o
> OBJ.mips-sgi-irix6.2/gdalbridge.o OBJ.mips-sgi-irix6.2/make_loc.o \
>          -lgis -lI -lproj -lm  -lz  
> ld: ERROR 33: Unresolved text symbol "GBGetSymbol" -- 1st referenced by
> OBJ.mips-sgi-irix6.2/gdalbridge.o.
> ld: INFO 152: Output file removed because of error.

This suggests that neither

	#if defined(__unix__)
nor
	#ifdef _WIN32

are true. Can you provide a suitable symbol which could be tested?

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