[GRASS-dev] Re: [bug #1140] (grass) Non-portable snprintf() used in
several programs
Paul Kelly
paul-grass at stjohnspoint.co.uk
Tue Jul 4 09:08:48 EDT 2006
Hello Markus!
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.
So I will work through those and see if I can change them not to use
snprintf(). Started it now. I feel if there's something where the length
of the resulting string really cannot be predicted, then we should use
G_asprintf() because it's there. It does seem to be a matter of personal
preference and philosophy though! But I think as Glynn has said before,
most of the places snprintf() is used the return value is not checked. So
if an overflow was prevented, and the string was not the expected value,
the program would just ignore it!
So to summarise - G_snprintf() would be useful to have to easily fix
the places that snprintf() was erroneously introduced - so you could put
it in, but I think we should discourage its use in favour of calculating
how long the string will be and allocating enough memory.
Paul
On Tue, 4 Jul 2006, Markus Neteler via RT wrote:
> Hi,
>
>
>
> the snprintf() is used as of today in:
>
>
>
> ./raster3d/r3.in.ascii/main.c
>
> ./db/drivers/dbf/dbfexe.c
>
> ./raster/r.support/front/front.c
>
> ./raster/r.support/front/check.c
>
> ./raster/r.support/front/run.c
>
> ./raster/r.support/modhead/check_un.c
>
> ./raster/r.support/modhead/modhead.c
>
> ./raster/r.support/modhead/ask_format.c
>
> ./lib/init/clean_temp.c
>
> ./lib/db/dbmi_client/select.c
>
> ./lib/gis/user_config.c
>
> ./lib/vector/dglib/examples/components.c
>
>
>
> I suggest to implement G_snprintf() and use that
>
> function everywhere. Then we can fix in a single place
>
> if needed.
>
>
>
> Markus
>
>
>
> -------------------------------------------- Managed by Request Tracker
>
More information about the grass-dev
mailing list