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 D563CA00C2; Sat, 12 Mar 2022 02:11:08 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 677DF40E2D; Sat, 12 Mar 2022 02:11:08 +0100 (CET) Received: from mail-pj1-f54.google.com (mail-pj1-f54.google.com [209.85.216.54]) by mails.dpdk.org (Postfix) with ESMTP id E926E4067B for ; Sat, 12 Mar 2022 02:11:06 +0100 (CET) Received: by mail-pj1-f54.google.com with SMTP id z12-20020a17090ad78c00b001bf022b69d6so9668046pju.2 for ; Fri, 11 Mar 2022 17:11:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=gQ02jOIL29CPEHsEWmCgh0EIynPA2dSAy/QoCKvzmOs=; b=qyJuxopu8CUXPvesbciO3A+IParnFKgR3O+eFBRHOZTwqon0ev45Lk5UOsnJ9Fc3CJ 96IiPCxPeaRRiPY+TvRhOEum7A9KOd5d1lXmsBz9tJo1axVgF+onAoy/HPQx3KXkA6m2 F5/Y9Kl9qN1GrlLsWrWsKOui3ThUj1EE7BAN+Fwc/5BDeHoDgfeeFyBs0PPcZ1O18xB5 pCwPNv30jsU5Y8XVQG46kgAvGdbJb8UJ9P8Gw3yu9Logl7Bwitfqklqm8R6rKA6EtQkS k0PDk9zFq8SipapMroEEI1K6JLlkEUOSIkn2jqbf+5bBW94lmHetbG0H54mlMhJBUWsl MuYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=gQ02jOIL29CPEHsEWmCgh0EIynPA2dSAy/QoCKvzmOs=; b=YHCmX9u9RmVa+kq8zeYv3bt90SVwS1EdUeGUDUlDpX4GuDmunpdAEgHUkEAzxLnhwN vKaOIf1Gv0lJvDzgbj4gZ2VGnq1P573jqvvoyXDHgy/3ccCg65f3aO51WmLJB+9Hw9wS C2gXeorhtMn0104YB61EDFptT+pZj3/ebIC17ybsYM7o2tQLjkojYLa2uvtfMTDEaIgP mkXdtubeTuuP9JqdDgvWFssfIrMUrBLXA8c9RlaxatJ6I/dUyWqMme3PmeLyhGRUWAZN 5U9s2LlNAeRcWk3IpeQq9afSObOXEsKgDal9NlWVAEdrNi/d5aG8+xuY/39OCsrTBcJj F1bQ== X-Gm-Message-State: AOAM531SoeyqCtdDRS2onKt+irWT7K0RfwpYwUEt0vzUfxVAeMqLgSFF wo7Xa1J/EdU832Hdbm3jjznDkw== X-Google-Smtp-Source: ABdhPJyJKJmzy7VLLJMTW9BZ3HgoFIC4hJzYZ8fsSm+DfkSJfZ8NivSXeqJcpl17kA6DmahrStv0zw== X-Received: by 2002:a17:90b:384b:b0:1bf:12d8:62c0 with SMTP id nl11-20020a17090b384b00b001bf12d862c0mr25023388pjb.142.1647047465877; Fri, 11 Mar 2022 17:11:05 -0800 (PST) Received: from hermes.local (204-195-112-199.wavecable.com. [204.195.112.199]) by smtp.gmail.com with ESMTPSA id gw19-20020a17090b0a5300b001c5c937384bsm631361pjb.52.2022.03.11.17.11.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Mar 2022 17:11:05 -0800 (PST) Date: Fri, 11 Mar 2022 17:11:02 -0800 From: Stephen Hemminger To: Bruce Richardson Cc: dev@dpdk.org, pbhagavatula@marvell.com Subject: Re: [PATCH 5/5] eventdev: fix compilation with clang C++ builds Message-ID: <20220311171102.70e3d1f9@hermes.local> In-Reply-To: <20220311200523.1020050-6-bruce.richardson@intel.com> References: <20220311200523.1020050-1-bruce.richardson@intel.com> <20220311200523.1020050-6-bruce.richardson@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 On Fri, 11 Mar 2022 20:05:23 +0000 Bruce Richardson wrote: > When compiling on FreeBSD with clang and include checking enabled, > errors are emitted due to differences in how empty structs/unions are > handled in C and C++, as C++ structs cannot have zero size. > > ../lib/eventdev/rte_eventdev.h:992:2: error: union has size 0 in C, non-zero size in C++ > > Since the contents of the union are all themselves of zero size, > the actual union wrapper is unnecessary. We therefore remove it for C++ > builds - though keep it for C builds for safety and clarity of > understanding the code. The alignment constraint on the union is > unnecessary in the case where the whole struct is aligned on a 16-byte > boundary, so we add that constraint to the overall structure to ensure > it applies for C++ code as well as C. > > Fixes: 1cc44d409271 ("eventdev: introduce event vector capability") > Cc: pbhagavatula@marvell.com > > Signed-off-by: Bruce Richardson > --- > lib/eventdev/rte_eventdev.h | 12 +++++++++++- > 1 file changed, 11 insertions(+), 1 deletion(-) > > diff --git a/lib/eventdev/rte_eventdev.h b/lib/eventdev/rte_eventdev.h > index 67c4a5e036..42a5660169 100644 > --- a/lib/eventdev/rte_eventdev.h > +++ b/lib/eventdev/rte_eventdev.h > @@ -984,21 +984,31 @@ struct rte_event_vector { > }; > /**< Union to hold common attributes of the vector array. */ > uint64_t impl_opaque; > + > +/* empty structures do not have zero size in C++ leading to compilation errors > + * with clang about structure having different sizes in C and C++. > + * Since these are all zero-sized arrays, we can omit the "union" wrapper for > + * C++ builds, removing the warning. > + */ > +#ifndef __cplusplus > /**< Implementation specific opaque value. > * An implementation may use this field to hold implementation specific > * value to share between dequeue and enqueue operation. > * The application should not modify this field. > */ > union { > +#endif > struct rte_mbuf *mbufs[0]; > void *ptrs[0]; > uint64_t *u64s[0]; > +#ifndef __cplusplus > } __rte_aligned(16); > +#endif > /**< Start of the vector array union. Depending upon the event type the > * vector array can be an array of mbufs or pointers or opaque u64 > * values. > */ > -}; > +} __rte_aligned(16); > > /* Scheduler type definitions */ > #define RTE_SCHED_TYPE_ORDERED 0 Zero size arrays should be replaced by flexible arrays. Linux has this coccinelle script for that: // SPDX-License-Identifier: GPL-2.0-only /// /// Zero-length and one-element arrays are deprecated, see /// Documentation/process/deprecated.rst /// Flexible-array members should be used instead. /// // // Confidence: High // Copyright: (C) 2020 Denis Efremov ISPRAS. // Comments: // Options: --no-includes --include-headers virtual context virtual report virtual org virtual patch @initialize:python@ @@ def relevant(positions): for p in positions: if "uapi" in p.file: return False return True @r depends on !patch@ identifier name, array; type T; position p : script:python() { relevant(p) }; @@ ( struct name { ... * T array@p[\(0\|1\)]; }; | struct { ... * T array@p[\(0\|1\)]; }; | union name { ... * T array@p[\(0\|1\)]; }; | union { ... * T array@p[\(0\|1\)]; }; ) @only_field depends on patch@ identifier name, array; type T; position q; @@ ( struct name {@q T array[0]; }; | struct {@q T array[0]; }; ) @depends on patch@ identifier name, array; type T; position p : script:python() { relevant(p) }; // position @q with rule "only_field" simplifies // handling of bitfields, arrays, etc. position q != only_field.q; @@ ( struct name {@q ... T array@p[ - 0 ]; }; | struct {@q ... T array@p[ - 0 ]; }; ) @script: python depends on report@ p << r.p; @@ msg = "WARNING use flexible-array member instead (https://www.kernel.org/doc/html/latest/process/deprecated.html#zero-length-and-one-element-arrays)" coccilib.report.print_report(p[0], msg) @script: python depends on org@ p << r.p; @@ msg = "WARNING use flexible-array member instead (https://www.kernel.org/doc/html/latest/process/deprecated.html#zero-length-and-one-element-arrays)" coccilib.org.print_todo(p[0], msg)