From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:41479) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rat44-0000Az-Ff for qemu-devel@nongnu.org; Wed, 14 Dec 2011 12:56:25 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rat43-0003e7-51 for qemu-devel@nongnu.org; Wed, 14 Dec 2011 12:56:24 -0500 Received: from v220110690675601.yourvserver.net ([78.47.199.172]:52303) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rat42-0003dE-VM for qemu-devel@nongnu.org; Wed, 14 Dec 2011 12:56:23 -0500 Message-ID: <4EE8E308.7010005@weilnetz.de> Date: Wed, 14 Dec 2011 18:55:20 +0100 From: Stefan Weil 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> <4EE8DABC.8050902@codemonkey.ws> In-Reply-To: <4EE8DABC.8050902@codemonkey.ws> 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: Anthony Liguori Cc: Peter Maydell , qemu-devel@nongnu.org, Avi Kivity Am 14.12.2011 18:19, schrieb Anthony Liguori: > 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 Would 's' instead of '_' work? struct sCamelCase; typedef struct sCamelCase { // ... } CamelCase; It does not violate any standard... Regards, Stefan Weil