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