From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KSYq3-00043V-Ao for qemu-devel@nongnu.org; Mon, 11 Aug 2008 10:57:39 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KSYq1-00040e-HI for qemu-devel@nongnu.org; Mon, 11 Aug 2008 10:57:38 -0400 Received: from [199.232.76.173] (port=42800 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KSYq1-00040F-AA for qemu-devel@nongnu.org; Mon, 11 Aug 2008 10:57:37 -0400 Received: from hs-out-0708.google.com ([64.233.178.244]:65225) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KSYq0-00082I-Tb for qemu-devel@nongnu.org; Mon, 11 Aug 2008 10:57:37 -0400 Received: by hs-out-0708.google.com with SMTP id k27so163440hsc.2 for ; Mon, 11 Aug 2008 07:57:36 -0700 (PDT) Message-ID: <48A0533A.9020707@codemonkey.ws> Date: Mon, 11 Aug 2008 09:56:58 -0500 From: Anthony Liguori 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> <48A05150.2040405@qumranet.com> In-Reply-To: <48A05150.2040405@qumranet.com> 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 Avi Kivity wrote: > 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. 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