[GRASS-dev] Re: [bug #1140] (grass) Non-portable snprintf() used
in several programs
paul-grass at stjohnspoint.co.uk
Tue Jul 4 16:07:09 EDT 2006
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).
More information about the grass-dev