From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:32938) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RasUv-0001O9-Ls for qemu-devel@nongnu.org; Wed, 14 Dec 2011 12:20:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RasUp-0003TW-Qc for qemu-devel@nongnu.org; Wed, 14 Dec 2011 12:20:05 -0500 Received: from mail-yw0-f45.google.com ([209.85.213.45]:54453) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RasUp-0003Ss-O0 for qemu-devel@nongnu.org; Wed, 14 Dec 2011 12:19:59 -0500 Received: by yhgg71 with SMTP id g71so1689541yhg.4 for ; Wed, 14 Dec 2011 09:19:59 -0800 (PST) Message-ID: <4EE8DABC.8050902@codemonkey.ws> Date: Wed, 14 Dec 2011 11:19:56 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <1323879637-16901-1-git-send-email-aliguori@us.ibm.com> <1323879637-16901-2-git-send-email-aliguori@us.ibm.com> <4EE8D506.8090905@codemonkey.ws> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1/4] memory: make memory API parsable by gtkdoc-scan List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: qemu-devel@nongnu.org, Avi Kivity On 12/14/2011 11:11 AM, Peter Maydell wrote: > On 14 December 2011 16:55, Anthony Liguori wrote: >> I think in this case, we're just going to have to deviate from the standard. >> The benefit is great, the practice is widespread, and there's no immediate >> likelihood of changing glib's coding style practices. >> >> I still think we should adhere to this policy where ever possible but I >> think we'll have to make an exception for extracting documentation. > > Disagree. A docs tool that requires us to change our coding/naming > conventions (as opposed to merely how we mark stuff up in comments > or whatever) is a broken tool. Doubly so if it mandates violation > of the C standards. > > We want to be able to document the structs/whatever we have now, > not only after we've done some enormous change to every struct we > have to bring it into line with somebody else's conventions. If you have a better suggestion, I'm all for it. But since C is not the most parseable language ever invented, basically every tool comes with constraints about coding style. We can spend forever searching for the perfect tool, invent one ourselves, or just suck it up and use what's already out there. The C language enforcement police aren't going to come knocking at our doors tomorrow. This doesn't create a bug or remove a feature. At some level, we need to be pragmatic. Regards, Anthony Liguori > > -- PMM >