[GRASS5] [bug #1140] (grass) Non-portable snprintf() used in several programs

GRASS GRASS developer
1

this bug's URL: http://intevation.de/rt/webrt?serial_num=1140
-------------------------------------------------------------------------

Subject: Non-portable snprintf() used in several programs

Platform: Irix
grass obtained from: CVS
grass binary for platform: Compiled from Sources
GRASS Version: CVSreleasebranch_26_april_2002_5_0_0 grass checked out 20020618

I have already mentioned this problem on the grass5 mailing list, but was just reading the descriptions of types of bugs and realised this is a release-critical one, since it wasn't present in earlier versions and has only appeared in the last six months or so since I started using GRASS. Therefore I am obliging by reporting it. There are probably more important things GRASS developers could be working on fixing but I think attention to detail and overall code quality and portability is very important.

The following programs contain references to the snprintf() function and therefore fail to compile on the IRIX 6.2 system I am using.

Compilation error in module: src/libes/dbmi/clients (ignored)
Compilation error in module: src/display/d.db (ignored)
Compilation error in module: src/display/d.what.db (ignored)
Compilation error in module: src/display/d.what.vect (ignored)
Compilation error in module: src/mapdev/v.db.reclass (ignored)
Compilation error in module: src/mapdev/v.in.mif (ignored)
Compilation error in module: src/mapdev/v.in.shape (ignored)
Compilation error in module: src/mapdev/v.out.shape (ignored)
Compilation error in module: src/mapdev/v.to.db (ignored)
Compilation error in module: src/raster/r.in.shape (ignored)
Compilation error in module: src/sites/s.in.dbf (ignored)
Compilation error in module: src.contrib/GMSL/NVIZ2.2 (ignored)

(This list may not be exhaustive; I didn't attempt to compile every module.)

It was also mentioned in the mailing list before that even on systems that do provide snprintf(), the return value when an error occurs is not standardised, so that is another reason for not relying on the system library version.

Paul Kelly

-------------------------------------------- Managed by Request Tracker

2

Request Tracker wrote:

It was also mentioned in the mailing list before that even on systems
that do provide snprintf(), the return value when an error occurs is
not standardised, so that is another reason for not relying on the
system library version.

AFAIK, there are only two possible behaviours in this case:

1. Return a negative value

2. Return the number of characters which would have been written,
excluding the trailing NUL.

So, using:

  n = snprintf(buff, size, ...);
  if (n < 0 || n >= size)
    G_fatal_error(...);

should handle either case.

That still doesn't solve the problem of needing snprintf() in the
first place. If we are going to rely upon a third-party library, we
should probably look for one which provides asprintf().

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

3

On Thu, Jun 27, 2002 at 11:05:03AM +0100, Glynn Clements wrote:

Request Tracker wrote:

> It was also mentioned in the mailing list before that even on systems
> that do provide snprintf(), the return value when an error occurs is
> not standardised, so that is another reason for not relying on the
> system library version.

That still doesn't solve the problem of needing snprintf() in the
first place. If we are going to rely upon a third-party library, we
should probably look for one which provides asprintf().

We should figure out what third library to use on Irix
and publish a description for people on Irix.
I'm not sure that we should make GRASS completly use snprintf()
from a third party library for all cases.