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

[Anthony Liguori]

Avi Kivity wrote:
> Anthony Liguori wrote:
> > Blue Swirl wrote:
> > > On 8/9/08, Anthony Liguori <address@hidden> 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