From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KSYhd-0001B1-4Z for qemu-devel@nongnu.org; Mon, 11 Aug 2008 10:48:57 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KSYhb-00016p-4G for qemu-devel@nongnu.org; Mon, 11 Aug 2008 10:48:56 -0400 Received: from [199.232.76.173] (port=52680 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KSYhb-00016e-1e for qemu-devel@nongnu.org; Mon, 11 Aug 2008 10:48:55 -0400 Received: from il.qumranet.com ([212.179.150.194]:21022) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KSYha-0006SC-Gr for qemu-devel@nongnu.org; Mon, 11 Aug 2008 10:48:54 -0400 Message-ID: <48A05150.2040405@qumranet.com> Date: Mon, 11 Aug 2008 17:48:48 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC, PATCH] Add -Wstrict-prototypes, maybe later -Wmissing-prototypes References: <489DE0C7.9000505@codemonkey.ws> <48A04ACD.5090900@codemonkey.ws> In-Reply-To: <48A04ACD.5090900@codemonkey.ws> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Anthony Liguori wrote: > Blue Swirl wrote: >> On 8/9/08, Anthony Liguori 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. 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. -- error compiling committee.c: too many arguments to function