From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0144.outbound.protection.outlook.com [157.56.110.144]) by dpdk.org (Postfix) with ESMTP id C60842E7B for ; Wed, 8 Apr 2015 23:55:27 +0200 (CEST) Received: from CY1PR0101MB0987.prod.exchangelabs.com (25.160.224.149) by CY1PR0101MB0986.prod.exchangelabs.com (25.160.224.148) with Microsoft SMTP Server (TLS) id 15.1.130.23; Wed, 8 Apr 2015 21:55:25 +0000 Received: from CY1PR0101MB0987.prod.exchangelabs.com ([25.160.224.149]) by CY1PR0101MB0987.prod.exchangelabs.com ([25.160.224.149]) with mapi id 15.01.0130.020; Wed, 8 Apr 2015 21:55:25 +0000 From: Don Provan To: "Butler, Siobhan A" , Thomas Monjalon , "dev@dpdk.org" Thread-Topic: [dpdk-dev] tools brainstorming Thread-Index: AQHQcejxJwfH6pJA1UyASkkYyghI7J1DnihA Date: Wed, 8 Apr 2015 21:55:24 +0000 Message-ID: References: <3571725.20GtF5MAnU@xps13> <0C5AFCA4B3408848ADF2A3073F7D8CC86D58F9C2@IRSMSX109.ger.corp.intel.com> In-Reply-To: <0C5AFCA4B3408848ADF2A3073F7D8CC86D58F9C2@IRSMSX109.ger.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [209.234.132.35] authentication-results: intel.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0101MB0986; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(77156002)(86362001)(87936001)(74316001)(2656002)(92566002)(102836002)(46102003)(107886001)(2501003)(2900100001)(76176999)(106116001)(2950100001)(33656002)(62966003)(40100003)(66066001)(122556002)(54356999)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0101MB0986; H:CY1PR0101MB0987.prod.exchangelabs.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(5002010)(5005006); SRVR:CY1PR0101MB0986; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0101MB0986; x-forefront-prvs: 0540846A1D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: bivio.net X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2015 21:55:24.9793 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8731bc55-0e76-4eb7-ae4b-401e56037945 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0101MB0986 Subject: Re: [dpdk-dev] tools brainstorming X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 21:55:28 -0000 >NOTE Please avoid, as much as possible, including headers from other heade= rs file. Doing so should be properly explained and justified. Actually, I think a *failure* to #include other header files that this head= er file depends on should be what needs explained and justified. It drives = me crazy when a header file forces me to figure out what header files it de= pends on and then forces me to include them in my sources even though my so= urces don't use them. Especially when #include is such a straightforward wa= y to document the dependency while keeping me out of it. Or are you only talking about when the header file doesn't depend on the he= ader files its #including? If so, then I'd prefer ruling it out entirely ra= ther than saying it needs to be justified. >For consistency, getopt(3) should be used to parse options. I assume this means the getopt() family, and I'd expect getopt_long() to be= used normally. (If it were me, I'd *encourage* getopt_long() over getopt()= .) >not::=20 > if (!*p) I'm not sure why you'd bother to rule out this common idiom or the similar = NULL pointer check. Are "if (*p)" and "if (p)" also prohibited, or just the= ir negations? >Values in return statements should be enclosed in parentheses. Please don't encourage people to have this silly habit. It makes no more se= nse than insisting variables be set with "x =3D (-1)". >static void > usage() This has nothing to do with the point being made here in your document, but= surely you want to insist on "static void usage(void)", right? In fact, yo= u might mention parameterless functions explicitly in the section on functi= on declarations. Everything else looks pretty cool. I'm surprised and impressed. -don provan