From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f54.google.com (mail-wm0-f54.google.com [74.125.82.54]) by dpdk.org (Postfix) with ESMTP id 5731D8D96 for ; Tue, 10 Nov 2015 18:12:48 +0100 (CET) Received: by wmvv187 with SMTP id v187so18653371wmv.1 for ; Tue, 10 Nov 2015 09:12:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind_com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to; bh=btxsYBVn+7GhLjladYjpMc0wbdd2gQU81MsFhcai0pw=; b=VTbAj9JZSOVoVUgwmU99IVV87s4fCgu2K3jOro7Rmmezas5ner5rGB+6exdYfbdUmf r6qpmi2NfTBQ7XoB0t6JKQz893AcTYm3K5dk0ivhnDhfo8mhK6TcJgSInBfn3hAhiL3R D3fogUC1qd2IxMcIrCrSZhMvR7HvbOLsSGNrdEhR8/mxvNYVz/AlgeR3GTd6jThI6imM GHg7A/TOnSZ7bAFN3hnlutgADmSL2McCWdPuwEo3UKffoziH5rI/ejFO6oOYqERyDh2Z ly9PhMSARTn6ergqGoTqK3YSksTsSGQl8ZjwL9Pc7A7MNBY29Skn825QLM1LfBXEmkaa zEqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-type :content-disposition:in-reply-to; bh=btxsYBVn+7GhLjladYjpMc0wbdd2gQU81MsFhcai0pw=; b=EZQPbuRpYkYIGn9KHQv9DXH9uZMQSA1o44PpITD1M3yl1G7lA+yxnrioBseaoi9en2 FVUkfbEwn5bHRqP/2Omi5AvWnjk5wqTaCDXbVuXZJiK73biYTVQrM8k1mkZgw4fDlQ/3 wxz+i9EuwoowihRx69yNB8ByrI8qOe4chuXklHk9n0aDFrh1B6Of2ljZmBOaQUCXK/Jd lDRGdoeAjwDXGN0rDZeFyv+59vmbYdd555Zy8pW1SCJce7r8JNGZmcPW0/R37/RTLBa/ 6uKUc74yRGOkW69vWfenWlcTyh6EVV8DM4EVX7LYQIJvl9wVfV3XRh1xU4VqDkC4vDFs 3AwQ== X-Gm-Message-State: ALoCoQnVDrj8uGdl97Il/3puL1y715V+R01xQaoTl2JWA4HfrcTsYcp6L1snLeab/Gw5gKZ05OKA X-Received: by 10.28.11.207 with SMTP id 198mr33080066wml.47.1447175568177; Tue, 10 Nov 2015 09:12:48 -0800 (PST) Received: from 6wind.com (guy78-3-82-239-227-177.fbx.proxad.net. [82.239.227.177]) by smtp.gmail.com with ESMTPSA id om1sm4536605wjc.2.2015.11.10.09.12.46 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 10 Nov 2015 09:12:47 -0800 (PST) Date: Tue, 10 Nov 2015 18:12:28 +0100 From: Adrien Mazarguil To: "Richardson, Bruce" Message-ID: <20151110171228.GY4013@6wind.com> Mail-Followup-To: "Richardson, Bruce" , Stephen Hemminger , Thomas Monjalon , "dev@dpdk.org" References: <4698587.GS9blBozDC@xps13> <20151104102418.GN3518@6wind.com> <20151104103957.4cabd090@xeon-e3> <20151105150918.GV3518@6wind.com> <20151106171007.GB19512@bricha3-MOBL3> <20151106172227.GC19512@bricha3-MOBL3> <20151109133905.GL4013@6wind.com> <59AF69C657FD0841A61C55336867B5B03598018B@IRSMSX103.ger.corp.intel.com> <20151110160806.GV4013@6wind.com> <59AF69C657FD0841A61C55336867B5B035981593@IRSMSX103.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <59AF69C657FD0841A61C55336867B5B035981593@IRSMSX103.ger.corp.intel.com> Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH v3 2/4] ethdev: move error checking macros to header 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: Tue, 10 Nov 2015 17:12:48 -0000 On Tue, Nov 10, 2015 at 04:21:10PM +0000, Richardson, Bruce wrote: > > > > -----Original Message----- > > From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com] > > Sent: Tuesday, November 10, 2015 4:08 PM > > To: Richardson, Bruce > > Cc: Stephen Hemminger ; Thomas Monjalon > > ; dev@dpdk.org > > Subject: Re: [dpdk-dev] [PATCH v3 2/4] ethdev: move error checking macros > > to header > > > > On Mon, Nov 09, 2015 at 02:02:28PM +0000, Richardson, Bruce wrote: > > [...] > > > > From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com] > > [...] > > > > Untested but I guess modifying that function accordingly would look > > like: > > > > > > > > static inline void > > > > rte_pmd_debug_trace(const char *func_name, const char *fmt, ...) { > > > > va_list ap; > > > > va_start(ap, fmt); > > > > > > > > static __thread char buffer[vsnprintf(NULL, 0, fmt, ap)]; > > > > > > > > va_end(ap); > > > > va_start(ap, fmt); > > > > vsnprintf(buffer, sizeof(buffer), fmt, ap); > > > > va_end(ap); > > > > rte_log(RTE_LOG_ERR, RTE_LOGTYPE_PMD, "%s: %s", func_name, > > > > buffer); } > > > > > > > > > > Looks a much better option. > > > > > > From this, though, I assume then that we are only looking to support the > > -pedantic flag in conjuction with c99 mode or above. Supporting -pedantic > > with the pre-gcc-5 versions won't allow that to work though, as variably > > sized arrays only came in with c99, and were gnu extensions before that. > > > > Right, -pedantic must follow a given standard such as -std=gnu99 otherwise > > it's meaningless. > > > > However pre-GCC 5 is fine for most if not all features we use, see: > > > > https://gcc.gnu.org/c99status.html > > > > Mixed code and declarations are supported since GCC 3.0, __VA_ARGS__ in > > macros since GCC 2.95 and variable length arrays since GCC 0.9, so as long > > as we use a version that implements -std=gnu99 (or -std=c99 to be really > > pedantic), it's fine. > > > > Besides DPDK already uses C99 extensively, even a few C11 features (such > > as > > embedded anonymous struct definitions) currently supported in C99 mode as > > compiler extensions. I think we can safely ignore compilers that don't > > support common C99 features. > > > > -- > > Adrien Mazarguil > > 6WIND > > Actually my point was slightly different. > If we are supporting "-pedantic" in header files because "we don't know what compiler flags users are going to pass when", then we need to support it in C90 mode to do the job properly. If you take gcc 4.8 and compile some code with "-pedantic" as the only C-flag you are going to get lots of errors because it will default to C90 mode with pedantic, which means no varargs macros at all. Agreed, exported headers should actually be C90 compliant for these reasons but C99 would be a start. I didn't know GCC 5 switched to C99 by default (don't worry, I do not intend to go back to C90). > This limits the usefulness of supporting pedantic flag at all in our header files, since we only support it in certain situations with non-latest compilers. I won't deny this, as the goal is partly to appease pedantic people like myself. Using standard methods for doing things should be preferred over extensions for compatibility with the unknown, unless there is no other way. -- Adrien Mazarguil 6WIND