From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KScV9-0003d4-DB for qemu-devel@nongnu.org; Mon, 11 Aug 2008 14:52:19 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KScV5-0003Ya-VB for qemu-devel@nongnu.org; Mon, 11 Aug 2008 14:52:17 -0400 Received: from [199.232.76.173] (port=52707 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KScV5-0003YC-DX for qemu-devel@nongnu.org; Mon, 11 Aug 2008 14:52:15 -0400 Received: from wf-out-1314.google.com ([209.85.200.174]:21183) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KScV4-0001Gz-Vy for qemu-devel@nongnu.org; Mon, 11 Aug 2008 14:52:15 -0400 Received: by wf-out-1314.google.com with SMTP id 27so4173675wfd.4 for ; Mon, 11 Aug 2008 11:52:12 -0700 (PDT) Message-ID: Date: Mon, 11 Aug 2008 21:52:11 +0300 From: "Blue Swirl" Subject: Re: [Qemu-devel] [RFC, PATCH] Add -Wstrict-prototypes, maybe later -Wmissing-prototypes In-Reply-To: <48A06D07.60103@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <489DE0C7.9000505@codemonkey.ws> <48A04ACD.5090900@codemonkey.ws> <48A05150.2040405@qumranet.com> <48A0533A.9020707@codemonkey.ws> <48A06B12.5000701@qumranet.com> <48A06D07.60103@codemonkey.ws> 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 On 8/11/08, Anthony Liguori wrote: > Avi Kivity wrote: > > > > > You lose the switch(nb_args) in monitor_handle_command() so it comes out > even. You don't need to cast anything -- though you do need to change all > the callbacks to accept an argument array. > > > > And to either explicitly cast each argument or explicitly parse each > argument. It touches quite a bit of places in the code and makes the > callbacks quite a bit more complicated. > > Using a void * is a one line change and works on all modern systems. Seems > like a winner to me :-) I vote for this. The other solutions do not improve type safety (except for union) and they are more complex.