[GRASS5] v.in.shape snprintf() problem

[Paul Kelly]

Is the following patch acceptable for a fix to v.in.shape to avoid a 'bus
error' when importing an area coverage? The problem seems to be that the
third-party snprintf library I use to get around the problem of some GRASS
programs containing this function doesn't support the '%f' format string.
After a bit of thought this seems logical enough to me as by using %f you
can control the exact length of the string anyway using only sprintf,
which avoids the need to use snprintf anyway. Is this correct?

Index: lines.c
===================================================================
RCS file: /grassrepository/grass/src/mapdev/v.in.shape/lines.c,v
retrieving revision 1.4
diff -u -r1.4 lines.c
--- lines.c     12 Jun 2002 00:03:08 -0000      1.4
+++ lines.c     14 May 2003 13:30:30 -0000
@@ -1102,8 +1102,8 @@

   retbuf = (char *)malloc( 33 );

-  snprintf( xbuf, 127, "%065.20f", xtmp );
-  snprintf( ybuf, 127, "%065.20f", ytmp );
+  sprintf( xbuf, "%065.20f", xtmp );
+  sprintf( ybuf, "%065.20f", ytmp );

   indx_ptr = strchr( xbuf, '.' );
   strncpy( retbuf, indx_ptr - idigits, idigits );


Also the malloc in the line above; is that all right or should it be
malloc( 33*sizeof(char))
or is a char always a size of 1 on all platforms?

There is one other call to snprintf() in v.in.shape, line 848 in
vmap_import.c:
snprintf(buffer2, f_size + 1, "%d", DBFReadIntegerAttribute(hDBF, rec_num, cat_num));
Is there any obvious solution to remove this and make v.in.shape
completely free from snprintf() calls?

Paul