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 4C70D460B1; Sat, 18 Jan 2025 04:05:05 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id DFD004028A; Sat, 18 Jan 2025 04:05:04 +0100 (CET) Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mails.dpdk.org (Postfix) with ESMTP id 566954003C for ; Sat, 18 Jan 2025 04:05:03 +0100 (CET) Received: by linux.microsoft.com (Postfix, from userid 1213) id 9104020BEBFC; Fri, 17 Jan 2025 19:05:02 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 9104020BEBFC DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1737169502; bh=op3VOEiUbYgCFqdisssq2cZjDsghAhZtpf69YVtPsBs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ZCrNXN0vPtR0EMaJ7eQh88OWXk3VekjoJxh8/fEHCGPw0U6HvRvgBZ3ABAn6BpVav mXSksJHa3ZnmxDjypXts07H86EZM8w/q+rnOOhpi3bYD8QPKbuc6IuZpjpznzkY57+ 2ys/9EUoaHTSNhP1xpduj0VC/iVJZpB9Jhk9k2+Y= Date: Fri, 17 Jan 2025 19:05:02 -0800 From: Andre Muezerie To: Morten =?iso-8859-1?Q?Br=F8rup?= Cc: dev@dpdk.org, stephen@networkplumber.org, bruce.richardson@intel.com Subject: Re: [PATCH v13 3/3] drivers/net: add diagnostics macros to make code portable Message-ID: <20250118030502.GA25492@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <1735263196-2809-1-git-send-email-andremue@linux.microsoft.com> <1736992511-20462-1-git-send-email-andremue@linux.microsoft.com> <1736992511-20462-4-git-send-email-andremue@linux.microsoft.com> <98CBD80474FA8B44BF855DF32C47DC35E9F9BD@smartserver.smartshare.dk> <20250117035652.GA1891@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20250117035652.GA1891@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> User-Agent: Mutt/1.5.21 (2010-09-15) 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 Thu, Jan 16, 2025 at 07:56:52PM -0800, Andre Muezerie wrote: > On Thu, Jan 16, 2025 at 10:08:07AM +0100, Morten Brørup wrote: > > > From: Andre Muezerie [mailto:andremue@linux.microsoft.com] > > > Sent: Thursday, 16 January 2025 02.55 > > > > > > It was a common pattern to have "GCC diagnostic ignored" pragmas > > > sprinkled over the code and only activate these pragmas for certain > > > compilers (gcc and clang). Clang supports GCC's pragma for > > > compatibility with existing source code, so #pragma GCC diagnostic > > > and #pragma clang diagnostic are synonyms for Clang > > > (https://clang.llvm.org/docs/UsersManual.html). > > > > > > Now that effort is being made to make the code compatible with MSVC > > > these expressions would become more complex. It makes sense to hide > > > this complexity behind macros. This makes maintenance easier as these > > > macros are defined in a single place. As a plus the code becomes > > > more readable as well. > > > > Here is some food for thought and discussion... > > > > > @@ -2083,7 +2075,7 @@ dpaa2_dev_loopback_rx(void *queue, > > > if (unlikely((status & QBMAN_DQ_STAT_VALIDFRAME) == > > > 0)) > > > continue; > > > } > > > - fd[num_rx] = (struct qbman_fd *)qbman_result_DQ_fd(dq_storage); > > > + fd[num_rx] = RTE_PTR_DROP_QUALIFIERS(qbman_result_DQ_fd(dq_storage)); > > > > I do not think this makes the code more readable; quite the opposite. > > Before this, I could see which type the variable was being cast to. > > > > How about a macro that resembles "traditional" type casting: > > > > /** > > * Workaround to discard qualifiers (such as const, volatile, restrict) from a pointer, > > * without the compiler emitting a warning. > > * > > * @warning > > * Although this macro can be abused for casting a pointer to point to a different type, > > * alignment may be incorrect when casting to point to a larger type. E.g.: > > * struct s { > > * uint16_t a; > > * uint8_t b; > > * uint8_t c; > > * uint8_t d; > > * } v; > > * uint16_t * p = RTE_CAST_PTR(uint16_t *, &v.c); // "p" is not 16 bit aligned! > > */ > > #define RTE_CAST_PTR(type, ptr) \ > > ((type)(uintptr_t)(ptr)) > > > > > > Writing the above warning lead me down another path... > > Can we somehow use __typeof_unqual__? > > It is available in both GCC [1] and MSVC [2]. > > > > [1]: https://gcc.gnu.org/onlinedocs/gcc/Typeof.html > > [2]: https://learn.microsoft.com/en-us/cpp/c-language/typeof-unqual-c?view=msvc-170 > > > > > > We are making a workaround, and should take care to not endorse overusing it. > > Especially for other purposes than intended. > > > > Unfortunately, I think some of the type casts don't just remove qualifiers, but does exactly what my warning above describes: Casts a pointer to completely different type. > > If the new type is a larger type, the pointer's alignment becomes invalid, and if the compiler considers alignment a "qualifier", -Wcast-qual emits a warning about it. > > > > > > Backtracking a bit... > > If the macro is intended to remove qualifiers, and not to cast to a different type, RTE_PTR_DROP_QUALIFIERS(ptr) might be better than RTE_CAST_PTR(type, ptr). > > For brevity and to resemble the C23 keyword typeof_unqual, it could be named RTE_PTR_UNQUAL instead of RTE_PTR_DROP_QUALIFIERS. > > > > These are great suggestions, and __typeof_unqual__ seems to be exactly what we need to drop the qualifiers. I'll look more closely at the code and find out where a cast is actually being used for other purposes than removing the qualifier. I took a closer look at the code and this is what I found: * Only 2 places where qualifiers were being dropped were not casting to a different type. I used RTE_PTR_UNQUAL in those as suggested, for clarity. * I experimented with C23 typeof_unqual. It indeed works on gcc, clang and MSVC, but there are some details: a) With gcc the project needs to be compiled with -std=c2x. Many other warnings show up, unrelated to the scope of this patchset. Some look suspicious and should be looked at. An error also showed up, for which I sent out a small patch. b) When using typeof_unqual and passing "-Wcast-qual" to the compiler, a warning about the qualifier being dropped is emitted. The project currently uses "-Wcast-qual" Due to (a) I decided to not use typeof_unqual for now, but it would be trivial to change the macro in the future to do so. * All other places where I was using RTE_PTR_DROP_QUALIFIERS I'm using RTE_CAST_PTR now. I also think that the code became more readable by doing so.