Re: [Qemu-devel] [RFC, PATCH] Add -Wstrict-prototypes, maybe later -Wmissing-prototypes

[Anthony Liguori <anthony@codemonkey.ws>]

Avi Kivity wrote:
> Anthony Liguori wrote:
>> Blue Swirl wrote:
>>> On 8/9/08, Anthony Liguori <anthony@codemonkey.ws> wrote:
>>>  
>>>> Blue Swirl wrote:
>>>>
>>>>   
>>>>> Hi,
>>>>>
>>>>> 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.
>>>>>
>>>>>
>>>>>       
>>>>  As long as the plan is to fix all of those warnings, I think it's 
>>>> a good
>>>> 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