From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <olivier.matz@6wind.com> Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) by dpdk.org (Postfix) with ESMTP id 36A9DADBE for <dev@dpdk.org>; Wed, 25 Jun 2014 09:55:37 +0200 (CEST) Received: by mail-wi0-f173.google.com with SMTP id cc10so7377137wib.0 for <dev@dpdk.org>; Wed, 25 Jun 2014 00:55:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=oG028ZwKHi/AN4SF0elv1NmsEY1m/IgIlk4Np0gKF/0=; b=XaEG0HAy+NXmCOsQs+oIi0OyFPp2rJLnkEyIy2ZTZSP+nZL6k559oYV63yQHQ07xsN GIOsad4Skzex5hYUEvJrL8B6sCJlScrPV3uOPGYqmonuPXSloF1xj0/GSUJMLom5bu3i CVR9Wz+ebA8MgU8Gkg0Q4s7C93T2r75NKUe3lij9aSWQ+NiStZhrYNq2RmSBAJCVF32G 9sTPqZu6OTFNZGOrbgzycZOApNmmDUAsUfyv3bjNJ6kaxPFxzh6jdPqAwfMzfsAR3BqR +1iP1ZAK7Czurdtd0tx1HOT+NCftO+1tq4NNFHkD0+FL9MXmVoDCqW7QIxrIItBiuxFu 2PqA== X-Gm-Message-State: ALoCoQlNFvqT5N0sFrwr9xHqPoI3ltoySqepoSaO7rfZU+P6DakCr0GEQ2EaAC50HyZxZHJDA2xh X-Received: by 10.180.19.233 with SMTP id i9mr40366651wie.38.1403682955932; Wed, 25 Jun 2014 00:55:55 -0700 (PDT) Received: from [10.16.0.195] (6wind.net2.nerim.net. [213.41.180.237]) by mx.google.com with ESMTPSA id dj2sm50912821wib.11.2014.06.25.00.55.54 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 25 Jun 2014 00:55:55 -0700 (PDT) Message-ID: <53AA8083.8000900@6wind.com> Date: Wed, 25 Jun 2014 09:55:47 +0200 From: Olivier MATZ <olivier.matz@6wind.com> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.4.0 MIME-Version: 1.0 To: "Richardson, Bruce" <bruce.richardson@intel.com>, Stephen Hemminger <stephen@networkplumber.org> References: <20140624090253.140206a7@nehalam.linuxnetplumber.net> <59AF69C657FD0841A61C55336867B5B02CEE3359@IRSMSX103.ger.corp.intel.com> <20140624105427.166c21bf@nehalam.linuxnetplumber.net> <59AF69C657FD0841A61C55336867B5B02CEE345B@IRSMSX103.ger.corp.intel.com> In-Reply-To: <59AF69C657FD0841A61C55336867B5B02CEE345B@IRSMSX103.ger.corp.intel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dev@dpdk.org" <dev@dpdk.org> Subject: Re: [dpdk-dev] [PATCH 1/3] stringfns: remove rte_snprintf X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Wed, 25 Jun 2014 07:55:37 -0000 Hi Bruce, On 06/24/2014 08:00 PM, Richardson, Bruce wrote: >> I want to get it out now rather than some 2 year life cycle. >> The issue was discussed and marking it as deprecated breaks the build. >> Alternate is removing all instances and adding: >> >> #define rte_snprintf snprintf >> >> in header file for user compatiablity. > > We can remove it from all our apps and then mark as deprecated and all our code would still build. > An interesting point I'd never thought of is, is it right for us to force user apps to treat all warnings as errors? Perhaps we should also consider removing -Werror from the CFLAGS when using rte.extapp.mk. I don't understand why removing a function like rte_snprintf() in a new version of DPDK would be a problem. Yes, it would break the build of external applications, but that's the best way to fix the problem in the external code. Adding a compatibility layer just delays the issue. Maybe having a line about this in a "release note" or a "porting guide" would be enough? It could even references the commit id, showing how to solve the issue. About the -Werror flag, I would say that removing it is not a good idea. From my experience, many issues are pointed out by warnings, and forcing the compiler to stop on warning helps to have better code quality. Regards, Olivier