From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KSYpB-0002xO-SG for qemu-devel@nongnu.org; Mon, 11 Aug 2008 10:56:46 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KSYp7-0002s9-Vg for qemu-devel@nongnu.org; Mon, 11 Aug 2008 10:56:42 -0400 Received: from [199.232.76.173] (port=42754 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KSYp7-0002rw-MF for qemu-devel@nongnu.org; Mon, 11 Aug 2008 10:56:41 -0400 Received: from ecfrec.frec.bull.fr ([129.183.4.8]:47934) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KSYp6-0007pq-N3 for qemu-devel@nongnu.org; Mon, 11 Aug 2008 10:56:41 -0400 Subject: Re: [Qemu-devel] [RFC, PATCH] Add -Wstrict-prototypes, maybe later -Wmissing-prototypes From: Laurent Vivier In-Reply-To: <48A05150.2040405@qumranet.com> References: <489DE0C7.9000505@codemonkey.ws> <48A04ACD.5090900@codemonkey.ws> <48A05150.2040405@qumranet.com> Content-Type: text/plain; charset=UTF-8 Date: Mon, 11 Aug 2008 16:56:36 +0200 Message-Id: <1218466596.3871.37.camel@frecb07144> Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 Le lundi 11 ao=C3=BBt 2008 =C3=A0 17:48 +0300, Avi Kivity a =C3=A9crit : > Anthony Liguori wrote: > > Blue Swirl wrote: > >> On 8/9/08, Anthony Liguori wrote: > >> =20 > >>> Blue Swirl wrote: > >>> > >>> =20 > >>>> Hi, > >>>> > >>>> I made a series of patches that add -Wstrict-prototypes to the CFL= AGS > >>>> 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. > >>>> > >>>> > >>>> =20 > >>> As long as the plan is to fix all of those warnings, I think it's = a=20 > >>> good > >>> idea. > >>> =20 > >> > >> 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 th= is > >> case, they can vary: > >> =20 > > > > You could just switch void (*handler)() to void *handler.=20 >=20 > Function pointers might be wider than data pointers. >=20 > Looking at the usage, though, it looks like the best thing is to have a >=20 > void (*handler)(const char **args) >=20 > So we pass the array of arguments (could be zero length) to the handler= . I agree with that. Each command can be seen like a shell command and "handler" is like the "int main(int argc, char **argv)". Perhaps we can have an "int (*handler)(int argc, char **argv)" ? Regards, Laurent --=20 ----------------- Laurent.Vivier@bull.net ------------------ "La perfection est atteinte non quand il ne reste rien =C3=A0 ajouter mais quand il ne reste rien =C3=A0 enlever." Saint Exup=C3=A9ry