[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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 (X11/20080501)

Avi Kivity wrote:
Anthony Liguori wrote:
Blue Swirl wrote:
On 8/9/08, Anthony Liguori <address@hidden> wrote:
Blue Swirl wrote:


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

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.


Anthony Liguori

reply via email to

[Prev in Thread] Current Thread [Next in Thread]