[GRASS-dev] d.legend uses a static buffer for `map='

[Ivan Shmakov]

>>>>> Glynn Clements <glynn at gclements.plus.com> writes:

 >>>> Things I didn't change with this patch:

 >>>> * buffers related to SQL commands, because I know no appropriate
 >>>> Cpp macro for these;

 >>> I would suggest just adding e.g.:

 >>> #define SQL_COMMAND_MAX 4000

 >>> to the top of the file, then using that.

[...]

 >> There're just too many files for this macro to be defined.  Could
 >> there be a separate header to define the macros like this one?

 > Even if it's defined in a header, you still need to modify all those
 > files to use the constant in their array definitions.

	Yes.  Still, it saves a few lines (mostly context) per file in a
	unified diff.

 > AFAICT, most DB modules use the functions in
 > lib/db/dbmi_base/string.c (db_append_string etc) to construct SQL
 > queries, rather than using fixed-sized buffers.

	Even if it's so, I've seen quite a few cases where it wasn't the
	case.

 >> [...]

 >>>> * misused G_warning (), etc.; like:

 >> [...]

 >>>> there're just too many of these and I hope to handle them with a
 >>>> script;

[...]

 >> It much more a problem to get them changed automatically than to get
 >> them identified.

 > I don't think that an entirely automatic solution is desirable.
 > Trying to produce something which is robust enough not to introduce
 > bugs in some cases would probably take more time than making the
 > changes manually.

	Does changing the every occurence of (the whitespace was
	inserted for the sake of readability):

^([[:blank:]]+) sprintf [[:blank:]]*
                    \(([[:alpha:]][[:alnum:]_]),
                      (("[^"]*") | _\(("[^"]*"))\)
                      [[:blank:]]* (,[[:blank:]]*[^)]+)?
                      \);
                [[:blank:]]*
                (G_(warning|fatal_error|([[:alpha:]_]*_)?message))
                    [[:blank:]]*
                    \(\2\);

	with:

\1 \7 (_(\4\5), \6);

	sound reasonable to you?

 > E.g. with Emacs, it's easy enough to perform a compilation, then
 > repeatedly use "C-x `" (next-error) and "C-x e" (call-last-kbd-macro)
 > to fix a hundred cases in a few minutes while maintaining manual
 > oversight of the process.

	Indeed, I use C-x e quite extensively.  But what's more of an
	interest to me is the ability to describe the changes I'm
	suggesting in a concise, yet machine-processable way.  It's
	hardly possible for the changes like the above with the unified
	diff alone.