[GRASS-dev] compilation of grass on AIX 7.1

Glynn Clements glynn at gclements.plus.com
Mon Jul 29 06:04:54 PDT 2013


Hamish wrote:

> is it appropriate to backport r57238 to 6.x?

Yes for 6.5, probably not for 6.4 as it isn't urgent; the change only
suppresses warnings about "potential" issues, it doesn't fix actual
bugs.

> there are also quite a few like "G_fatal_error(buff);", can anything
> be done in the lib fn for them or do they all have to be changed to
> "G_fatal_error("%s", buff);" ?

They need to be changed. But not necessarily like that. First, ask why
the error message is a variable rather than a string literal.

If it's because error handling has been "wrapped", then unwrap it. 
E.g. we might decide to add an option to replace G_fatal_error (and
similar) with a macro which (optionally) adds __FILE__ and __LINE__,
but that's useless if the calls have been wrapped.

> [* many of those are hold-overs from pre- GRASS 5 and a
> sprintf(buff,..) in the lines above can be moved into the
> G_fatal_error()]

In such cases, the sprintf() should be eliminated.

> Lots of "G_warning(msg);"

Again: ask "why isn't 'msg' a string literal" first.

> and "G_debug(3, db_get_string(&sql));" to consider too.

For most of these, inserting the "%s" is probably the right solution,
although including a word or two of descriptive text might make the
debug information more useful (e.g. providing something to grep for).

-- 
Glynn Clements <glynn at gclements.plus.com>


More information about the grass-dev mailing list