From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 510FEA09E4; Fri, 29 Jan 2021 09:35:40 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id EEBA22400FB; Fri, 29 Jan 2021 09:35:39 +0100 (CET) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by mails.dpdk.org (Postfix) with ESMTP id C722240395 for ; Fri, 29 Jan 2021 09:35:37 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1611909336; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=z31kn4SPpM0mnSrk/jtI6jwlUwNXQE/UyAPc8Um8Pws=; b=JqnT/eMXEtDK14ukrWGaH6EcTj40HoqC6wvSoZd4f7om56CJNMFV/6sq1VRGK20ZeZsDqL 8eZxLJdeXdq3aCVLPjZqnQGtBfrLXC6/JbBIJq+g5wVMBmwcWWlOaVJ3YoTagiQAt0VNwK SwbzQZM6dNfnpIXbHzm8Fsf4y0W0cYs= Received: from mail-ua1-f69.google.com (mail-ua1-f69.google.com [209.85.222.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-488-7x2RyfcoOEyzU8c7Wa3Kjg-1; Fri, 29 Jan 2021 03:35:34 -0500 X-MC-Unique: 7x2RyfcoOEyzU8c7Wa3Kjg-1 Received: by mail-ua1-f69.google.com with SMTP id o24so2003497uap.15 for ; Fri, 29 Jan 2021 00:35:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=z31kn4SPpM0mnSrk/jtI6jwlUwNXQE/UyAPc8Um8Pws=; b=Z0HwQOpIjWLaRmYVBDF+87BMT29D2MbzIW9nBt5NmNR51LTpvXBCj3VZGplGxVdUp4 bvISpoWk7wEHyboBeXjWaYgwYqLYMYHHzbeirtrtoWyP0yvkKK2gZNmVRHAe/jACEtud j/kOeOnKHnIOeNQ0llWVpOD5opq9GSBvsUgLi6eb+MIhnmIbnIS7llgs43uvYdRbtUA8 Kk9+T8BMVJdMUj8GeXs+oSwR6FajuzKJCudRSvJdwMOU/mJBlMkA4gmga4J8/3O0tkGN 9f2h584IlXZXfzYAWa0HU4CvQ/mFLlv1UyK8f8W9hY27QPNw0h07N+VqViuV7/OecWl+ yJHw== X-Gm-Message-State: AOAM533+dGvBrCViPhWGGjMG3LuT4QnzYuB7YPyMxm/RmIeEsl1iMh6S oyc4Rso/Bk+lahA5MOtjs6ri2rE5e1lonwoqNfPFczoyOkmMVdUIsLo+dT/GEVLike1mTCIAzFE +CsvjiOU/19BS/+iSHhM= X-Received: by 2002:ab0:7087:: with SMTP id m7mr1984307ual.53.1611909334027; Fri, 29 Jan 2021 00:35:34 -0800 (PST) X-Google-Smtp-Source: ABdhPJwca+vci3hHySeGXiDrEqr7UlN5x5fcx1c2sQzIals1noQs+kTiyVfaJ72kSpT5vXufv87sHbwTi93+MB7fjIw= X-Received: by 2002:ab0:7087:: with SMTP id m7mr1984267ual.53.1611909333042; Fri, 29 Jan 2021 00:35:33 -0800 (PST) MIME-Version: 1.0 References: <20210114110606.21142-1-bruce.richardson@intel.com> <20210128141610.GI899@bricha3-MOBL.ger.corp.intel.com> <20210128151649.GJ899@bricha3-MOBL.ger.corp.intel.com> <3903937.VWLc1O45Db@thomas> <20210128173619.GL899@bricha3-MOBL.ger.corp.intel.com> In-Reply-To: <20210128173619.GL899@bricha3-MOBL.ger.corp.intel.com> From: David Marchand Date: Fri, 29 Jan 2021 09:35:22 +0100 Message-ID: To: Bruce Richardson Cc: Thomas Monjalon , techboard@dpdk.org, dev Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dmarchan@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [dpdk-techboard] [PATCH v6 2/8] eal: fix error attribute use for clang X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Thu, Jan 28, 2021 at 6:36 PM Bruce Richardson wrote: > > > > > We will never know about those compilers behavior, like how we caught > > > > > the clang issue and found an alternative. > > > > > > > > > > > > > So I understand, but I'm still concerned about breaking something that was > > > > previously working. It's one thing a DPDK developer catching issues with > > > > clang, quite another a user catching it when trying to build their own > > > > application. > > > > > > > > We probably need some other opinions on this one. > > > > > > > Adding Tech-board to see if we can get some more thoughts on this before I do > > > another revision of this set. > > > > What are the alternatives? > > > > The basic problem is what to do when a compiler is used which does not support > the required macros to flag an error for use of an internal-only function. > For example, we discovered this because clang does not support the #error > macro. *attribute* > > In those cases, as I see it, we really have two choices: > > 1 ignore flagging the error and silently allow possible use of the internal > function. > 2 have the compiler flag an error for an unknown macro > > The problem that I have with #2 is that without knowing the macro, the > compiler will likely error out any time a user app includes any header with > an internal function, even if the function is unused. > > On the other hand, the likelihood of impact if we choose #2 and do error out is > quite small, since modern clang versions will support the modern macro > checks we need, and just about any gcc versions we care about are going to > support #error. > > For #1, the downside is that we will miss error checks on some older > versions of gcc e.g. RHEL 7, and the user may inadvertently use an internal > function without knowing it. > > David, anything else to add here? Nop, fair summary. -- David Marchand