On Wed, 21 Apr 2010 22:51:33 +0200 Colomban Wendling lists.ban@herbesfolles.org wrote:
Hi,
I'm used to compile my programs with quite strict compiler options [1], and it made me see that the plugin API had some non-const arguments or field where it probably should have const ones - where string literals are most likely expected. I think of keybindings_set_item(), plugin_signal_connect(), the PluginInfo structure, etc. I think it is quite important since it makes the plugin API cleaner (IMHO) and allows to write more clean plugins (no more useless implicit promotions that may even be invalid).
I suppose this is due to source "foo" strings being const.
Attached a patch with the suggested changes.
Applied, thanks.
Although this changes some API code, I think it is completely API and ABI [2] compatible: changes only makes the API more permissive on given types.
On quite the same topic, would a patch that fixes a lot of small problems like that in Geany's core be appreciated? It isn't hard to do but I think it would clean the code a bit.
Yes, but only if it's clear that const is really meant, not just to silence compiler warnings.
I don't like casting away const (e.g. keybindings_set_item) but for the API it's OK when 'safe'.
[1] -Wall -W -O2 -Wunused -Wunreachable-code -Wformat=2 -Wundef -Wshadow -Wpointer-arith -Wbad-function-cast -Wwrite-strings -Wconversion -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wmissing-noreturn -Wmissing-format-attribute -Wredundant-decls -Wnested-externs -pedantic
BTW, which one causes the const literal string warnings?
(You might want to add -ansi or -std=foo for portability.)
Regards, Nick