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 E88BE43CAE for ; Thu, 14 Mar 2024 00:45:42 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D9AFB42E0E; Thu, 14 Mar 2024 00:45:42 +0100 (CET) Received: from mail-pl1-f178.google.com (mail-pl1-f178.google.com [209.85.214.178]) by mails.dpdk.org (Postfix) with ESMTP id EC3C240297 for ; Thu, 14 Mar 2024 00:45:40 +0100 (CET) Received: by mail-pl1-f178.google.com with SMTP id d9443c01a7336-1dd878da011so2637355ad.2 for ; Wed, 13 Mar 2024 16:45:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1710373540; x=1710978340; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=N8do5AorKNn626vXJ8vMj2ABiP+n5CkpSpqdAEiM06A=; b=swvfPN/9lEzSRncofcYSG4eUjSdyVHW2w4yxFuXDzkZjCTjOEyiXPY/BfyPtMQ6mLc CTg7iqJUM3BgrzGg2LWcJEzcAbZVOUl7OBZzSvz2H1lY+m8sqqYrKr0gEcuB98c3NOkY JT8JVYq+1+638RKf4pVYzvLeotHY9LedOc7aD/W/8uclsclV3PIYwCrLKWRkG0HnhVfC ej7VOthMtVd26sydTDQQgEKXGqi8OrSzseA1yxsP8fAw73IANZUH1aHGIJ3Hl/ZzoQ3S H0g4miWSg6QGiNXKAn1t8mV0LC2s2qQYJDeXcldZqYoJUqbTMiGQgRd3Tl8K+lIyuA4g VQVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710373540; x=1710978340; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=N8do5AorKNn626vXJ8vMj2ABiP+n5CkpSpqdAEiM06A=; b=vXPFEmMclYmPMwn2dlWHpr6ZMqMIdcX19dXEyDcE5Sw7L6u+mJnqTkZqjv73AWgcum KYATVU4IM6mLicvLt5XRcztj9m4j57DPCdCBMWIynDv+TIA6nOwGmYgmh+2c7EnTDGYn emmhVilHEdsDfBI6uO0q9cxzEI0O6MVMHQvkcFH5CZoU15lg9QHrmCzfOWsz4XwNyCmH ozy9D5nXC37Umgy2kr0kck5yeC6fgJWyQBo3h4wAFkm4OHnJBU8SsjekdYVLFcfFIrX2 ExGdOQB+as82fZ810rtPDsT8XiEbvaGMUAI6V10/jt+GY9AeL2y/eelJ6D0srekHIyZn 9OvA== X-Forwarded-Encrypted: i=1; AJvYcCWOiG795DvitjzqKJEaTg+JuWdRrqkjGSs3wxIsokLEePWzU1y3ogeIntZoZuTTScpfeT2Gn3E64OJCyotS4Uc= X-Gm-Message-State: AOJu0YwtVdGOkt1qukEupxgxQu39rS3FuywWw1UN9uvFiJu+XwAqUK2i MsWTM2FECpIDj10qhGqQju+74da/1WZ9gts/d17LTDIJuRdkPbfthBBK3oUcrus= X-Google-Smtp-Source: AGHT+IGnYhIkxV87PXufI6o9gbMc0mrK2K2PRJyOBob08yJB2F79/d2Qp2L4ejcc7ZGm/cDl01kbLw== X-Received: by 2002:a17:903:1cf:b0:1dd:afa1:3094 with SMTP id e15-20020a17090301cf00b001ddafa13094mr326209plh.36.1710373540020; Wed, 13 Mar 2024 16:45:40 -0700 (PDT) Received: from hermes.local (204-195-123-141.wavecable.com. [204.195.123.141]) by smtp.gmail.com with ESMTPSA id l8-20020a170903244800b001dd4bc67910sm186216pls.79.2024.03.13.16.45.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 Mar 2024 16:45:39 -0700 (PDT) Date: Wed, 13 Mar 2024 16:45:36 -0700 From: Stephen Hemminger To: Ashish Sadanandan Cc: Bruce Richardson , 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 Subject: Re: [PATCH 1/1] eal: add C++ include guard in generic/rte_vect.h Message-ID: <20240313164536.11fff597@hermes.local> In-Reply-To: References: <20240202051335.776290-1-ashish.sadanandan@gmail.com> <5751086.DvuYhMxLoT@thomas> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 On Fri, 2 Feb 2024 13:58:19 -0700 Ashish Sadanandan wrote: > > I think just having the extern "C" guard in all files is the safest choice, > > because it's immediately obvious in each and every file that it is correct. > > Taking the other option, to check any indirect include file you need to go > > 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. [Naturally, > > 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 But splashing this across all the internal driver headers is bad idea. It should only apply to header files that exported in final package.