[GRASS-dev] Re: [bug #1140] (grass) Non-portable snprintf() used in several programs

[Paul Kelly]

Glynn Clements wrote:
> Paul Kelly wrote:
> 
> 
>>I contend that most of those recent introductions of snprintf() probably 
>>don't need it. E.g. the first one (raster3d/r3.in.acii/main.c) can 
>>calculate the length of the string to be malloc'ed using strlen() so can 
>>guarantee to leave enough space. The second one (db/drivers/dbf/dbfexe.c) 
>>can use a fixed field width specifier for the %d format string to fix the 
>>length also - again predictable.
> 
> 
> Field width specifiers only control the minimum width of a field (i.e. 
> the amount of padding or the number of leading zeroes); a field can
> still be larger than the specified width.

Ah yes I realised that when I actually went to implement my proposed change.

> For %d, it's reasonable to assume a 32-bit integer, which means that
> it can never be more than 11 characters wide (10 digits, with a
> leading minus if negative).

Well in this case the existing code was allocating 32 bytes of space and 
then using snprintf so I think it should be safe to change the snprintf 
a simple sprintf in this case (db/drivers/dbf/dbfexe.c).