>>>>> Glynn Clements <[EMAIL PROTECTED]> 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.
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
