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

Glynn Clements glynn.clements at virgin.net
Wed May 14 13:42:35 EDT 2003


Paul Kelly wrote:

> 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 );

The fix seems OK, although the actual format looks rather odd.

> 
> Also the malloc in the line above; is that all right

Yes.

> or should it be
> malloc( 33*sizeof(char))

No.

> or is a char always a size of 1 on all platforms?

Yes.

> 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?

	sprintf(buffer2, "%d", DBFReadIntegerAttribute(hDBF, rec_num, cat_num));
	buffer2[f_size] = '\0';

buffer2 is 256 bytes long, so "%d" won't overflow it on any platform
where an "int" has less than 850 bits.

OTOH, it's arguable that, rather than silently truncating the string
to the field width, it should signal an error if the string won't fit.
Ditto for the other cases.

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




More information about the grass-dev mailing list