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 9ED5F43A54 for ; Fri, 2 Feb 2024 21:58:48 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 98C9942DB2; Fri, 2 Feb 2024 21:58:48 +0100 (CET) Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com [209.85.208.41]) by mails.dpdk.org (Postfix) with ESMTP id 8879C40272; Fri, 2 Feb 2024 21:58:46 +0100 (CET) Received: by mail-ed1-f41.google.com with SMTP id 4fb4d7f45d1cf-556c3f0d6c5so3022923a12.2; Fri, 02 Feb 2024 12:58:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706907526; x=1707512326; darn=dpdk.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=3/MuJrjGRkgu+0kLoEVvTUDSaDQKnChdSZ/pZP2rzo4=; b=lSpoydaVmzMD0FcRZ+z04lOTfLxls3e1k95Oj1RD+qjDM/oExXvqXQshKYhwrCdY/Z kz3/zJAe4r82x0OUSco/IhlN4CjmcXNlpFFkgEVfGeMN9JBWPFLAv61lOI+5lQWOZ9jP 2aNAQ1Uis7XPEDjM569549IgtbxJDhqB+uf/dl2ltrXG1OyReYrIwnsFMJGjN1qSy0M+ rDnoezVUfK4CrYPgyBzrrEP1M/eOOlky+M/hBsgkhw+WGzrUe6tOBMq09joQLYNDaUJ4 Y5UansijD9LFeVhy0IW7IATxJgAD4fc/JG6hpjsaVsx4p2hlMWT0p4fAyWD1kyYNxH+E YKKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706907526; x=1707512326; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=3/MuJrjGRkgu+0kLoEVvTUDSaDQKnChdSZ/pZP2rzo4=; b=hbj9NhJhk4WDxLSVAMaZ6l0CbA0rJlu7eim4DEJ5vELwLNekRhQV8IRX/JgJU7171y KrJB/fiq/iJLYuJTIS8tOlxN3gvLVptbBDDqbfvuhBzvH0e0gbctMwXrh7iwCqTVHYiU ZoE1GZ8ktPhMYbWIzPXNqLcEpor8MHwXH64urXoe5DA63u8tXz3I6Krm2vPbYwJa8g36 WfE9IgB/zWyNcIw/YkqRFu4C50pk1i1bW5qbcA6LMNjoj1i0Z2HfSrcX0+4ZnA1SNXkZ 4DmdEGmuV617rxmjp8JLDsAGG3corIs1Su8JDfV66Hgo+5sp2qMkNR2p4jQw/ctslCgk an3Q== X-Gm-Message-State: AOJu0Yx1ymuRWEVuqMZZXYe18gvynjFwMGJNxKR6xzlRox1VeiNf6XUN NA5RtE5rpeH9Mg6YshgOpMvMvxY+0qe4T4o/KlreGUYkJo/91BEuPYqdif2+vTocDwjzFj780F6 ZObIUkcXcTKfNb6opjfExHFfBP+0= X-Google-Smtp-Source: AGHT+IGxQOI2sq02AlrUWyjHAsj3QrGKsAn9YZP77hXFRarZ8fIpGuzRPhr884rNXOpEDUOib1DG7cFIbIeTh0zdpOg= X-Received: by 2002:a05:6402:888:b0:55f:f2ae:20ed with SMTP id e8-20020a056402088800b0055ff2ae20edmr567078edy.16.1706907525746; Fri, 02 Feb 2024 12:58:45 -0800 (PST) MIME-Version: 1.0 References: <20240202051335.776290-1-ashish.sadanandan@gmail.com> <5751086.DvuYhMxLoT@thomas> In-Reply-To: From: Ashish Sadanandan Date: Fri, 2 Feb 2024 13:58:19 -0700 Message-ID: Subject: Re: [PATCH 1/1] eal: add C++ include guard in generic/rte_vect.h To: Bruce Richardson Cc: Thomas Monjalon , dev@dpdk.org, nelio.laranjeiro@6wind.com, stable@dpdk.org, honnappa.nagarahalli@arm.com, konstantin.v.ananyev@yandex.ru, david.marchand@redhat.com, ruifeng.wang@arm.com Content-Type: multipart/alternative; boundary="000000000000bc942d06106c6041" X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org --000000000000bc942d06106c6041 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Feb 2, 2024 at 2:41=E2=80=AFAM Bruce Richardson wrote: > On Fri, Feb 02, 2024 at 10:18:23AM +0100, Thomas Monjalon wrote: > > 02/02/2024 06:13, Ashish Sadanandan: > > > The header was missing the extern "C" directive which causes name > > > mangling of functions by C++ compilers, leading to linker errors > > > complaining of undefined references to these functions. > > > > > > Fixes: 86c743cf9140 ("eal: define generic vector types") > > > Cc: nelio.laranjeiro@6wind.com > > > Cc: stable@dpdk.org > > > > > > Signed-off-by: Ashish Sadanandan > > > > Thank you for improving C++ compatibility. > > > > I'm not sure what is best to fix it. > > You are adding extern "C" in a file which is not directly included > > by the user app. The same was done for rte_rwlock.h. > > The other way is to make sure this include is in an extern "C" block > > in lib/eal/*/include/rte_vect.h (instead of being before the block). > > > > I would like we use the same approach for all files. > > Opinions? > > > I think just having the extern "C" guard in all files is the safest choic= e, > because it's immediately obvious in each and every file that it is correc= t. > Taking the other option, to check any indirect include file you need to g= o > finding what other files include it and check there that a) they have > include guards and b) the include for the indirect header is contained > within it. > > Adopting the policy of putting the guard in each and every header is also= a > lot easier to do basic automated sanity checks on. If the file ends in .h= , > we just use grep to quickly verify it's not missing the guards. [Naturall= y, > we can do more complete checks than that if we want, but 99% percent of > misses can be picked up by a grep for the 'extern "C"' bit] > > /Bruce > 100% agree with Bruce. It's a valid ideological argument that private headers don't need such safeguards, but it's difficult to enforce and easy to break during refactoring. - Ashish --000000000000bc942d06106c6041 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Feb 2, 2024 at 2:41=E2=80=AFAM Bruce Richardson <bruce.richardson@intel.com> w= rote:
On Fri, Fe= b 02, 2024 at 10:18:23AM +0100, Thomas Monjalon wrote:
> 02/02/2024 06:13, Ashish Sadanandan:
> > The header was missing the extern "C" directive which c= auses name
> > mangling of functions by C++ compilers, leading to linker errors<= br> > > complaining of undefined references to these functions.
> >
> > Fixes: 86c743cf9140 ("eal: define generic vector types"= )
> > Cc: nelio.laranjeiro@6wind.com
> > Cc: stable@d= pdk.org
> >
> > Signed-off-by: Ashish Sadanandan <ashish.sadanandan@gmail.com> >
> Thank you for improving C++ compatibility.
>
> I'm not sure what is best to fix it.
> You are adding extern "C" in a file which is not directly in= cluded
> by the user app. The same was done for rte_rwlock.h.
> The other way is to make sure this include is in an extern "C&quo= t; block
> in lib/eal/*/include/rte_vect.h (instead of being before the block). >
> I would like we use the same approach for all files.
> Opinions?
>
I think just having the extern "C" guard in all files is the safe= st choice,
because it's immediately obvious in each and every file that it is corr= ect.
Taking the other option, to check any indirect include file you need to go<= br> finding what other files include it and check there that a) they have
include guards and b) the include for the indirect header is contained
within it.

Adopting the policy of putting the guard in each and every header is also a=
lot easier to do basic automated sanity checks on. If the file ends in .h,<= br> we just use grep to quickly verify it's not missing the guards. [Natura= lly,
we can do more complete checks than that if we want, but 99% percent of
misses can be picked up by a grep for the 'extern "C"' bi= t]

/Bruce

100% agree with Bruce. It's = a valid ideological argument that private headers
don't need = such safeguards, but it's difficult to enforce and easy to break
dur= ing refactoring.

- Ashish
--000000000000bc942d06106c6041--