[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