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

[Glynn Clements]

Ivan Shmakov wrote:

>  >> 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. Although it doesn't provide
>  > consistency between modules, it makes it easier to find such
>  > constants if they're at the top of the file.
> 
> 	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.

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.

> [...]
> 
>  >> * misused G_warning (), etc.; like:
> 
> [...]
> 
>  >> there're just too many of these and I hope to handle them with a
>  >> script;
> 
>  > Note that those functions are tagged with:
> 
>  > __attribute__((format(printf,1,2)));
> 
>  > With gcc, you can use the option:
> 
>  > `-Wformat-nonliteral' If `-Wformat' is specified, also warn if the
>  > format string is not a string literal and so cannot be checked,
>  > unless the format function takes its format arguments as a `va_list'.
> 
>  > to identify problematic cases (although --with-nls will interfere
>  > with this).
> 
> 	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.

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.

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