|
From: | Anthony Liguori |
Subject: | Re: [Qemu-devel] [RFC, PATCH] Add -Wstrict-prototypes, maybe later -Wmissing-prototypes |
Date: | Mon, 11 Aug 2008 09:56:58 -0500 |
User-agent: | Thunderbird 2.0.0.14 (X11/20080501) |
Avi Kivity wrote:
Anthony Liguori wrote:Blue Swirl wrote:On 8/9/08, Anthony Liguori <address@hidden> wrote:Blue Swirl wrote:As long as the plan is to fix all of those warnings, I think it's a goodHi, I made a series of patches that add -Wstrict-prototypes to the CFLAGS and then -Wmissing-prototypes, both of which are enabled by Xen. I also fixed most warnings generated -Wstrict-prototypes and some of them for the -Wmissing-prototypes case. Compiling with -Wstrict-prototypes produces only one extra warning. I think this flag should be enabled.idea.The extra unfixed warning comes from monitor.c: typedef struct term_cmd_t { const char *name; const char *args_type; void (*handler)(); const char *params; const char *help; } term_cmd_t; The warning is generated because the definition of "handler" should also describe the parameters and not use the old () style. But in this case, they can vary:You could just switch void (*handler)() to void *handler.Function pointers might be wider than data pointers.
On what platforms? void (*)() was deprecated as a generic function pointer. IIUC, there is no replacement and the rationale for that is that the vast majority of people can just use 'void *'. The general technique is discouraged though.
Looking at the usage, though, it looks like the best thing is to have a void (*handler)(const char **args) So we pass the array of arguments (could be zero length) to the handler.
Yeah, it uglifies things quite a bit though. You lose all of the nice parsing and lack of casting.
Regards, Anthony Liguori
[Prev in Thread] | Current Thread | [Next in Thread] |