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 E61BBA034F; Sat, 16 Oct 2021 19:02:19 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7F68340040; Sat, 16 Oct 2021 19:02:19 +0200 (CEST) Received: from turing.lru.li (turing.lru.li [49.12.115.177]) by mails.dpdk.org (Postfix) with ESMTP id 187E84003C for ; Sat, 16 Oct 2021 19:02:19 +0200 (CEST) Received: from dell12.lru.li (unknown [IPv6:2001:1a80:303a:0:faca:b8ff:fe50:d072]) (Authenticated sender: georg) by turing.lru.li (Postfix) with ESMTPSA id B89A75E4A3D; Sat, 16 Oct 2021 17:02:18 +0000 (UTC) Received: by dell12.lru.li (Postfix, from userid 1000) id 10AB21A6E23; Sat, 16 Oct 2021 19:02:18 +0200 (CEST) Date: Sat, 16 Oct 2021 19:02:18 +0200 From: Georg Sauthoff To: Olivier Matz Cc: Thomas Monjalon , David Marchand , dev@dpdk.org Message-ID: References: <20210918114930.245387-1-mail@gms.tf> <20210918114930.245387-2-mail@gms.tf> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [dpdk-dev] [PATCH 1/1] net: fix aliasing issue in checksum computation 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" Hello, On Fri, Oct 15, 2021 at 04:39:02PM +0200, Olivier Matz wrote: > On Sat, Sep 18, 2021 at 01:49:30PM +0200, Georg Sauthoff wrote: > > That means a superfluous cast is removed and aliasing through a uint8_t > > pointer is eliminated. Note that uint8_t doesn't have the same > > strict-aliasing properties as unsigned char. > > Interesting. Out of curiosity, do you have links that explains > this? yes, I do. https://stefansf.de/post/type-based-alias-analysis/ has some nice examples and explains some things. Especially, it makes the point that it's the access that matters for yielding undefined behaviour (i.e. when violating strict-aliasing rules) and not the cast itself: "N.B. the standard only speaks about the type of an object and the type of an lvalue in order to access an object. Thus a pointer to an object x may be converted arbitrarily often to arbitrary object pointer types, and therefore even to incompatible types, as long as every access to x is done through an lvalue which type conforms to C11 section 6.5 paragraph 7." Section 'Character Type' in that article also addresses how uint8_t isn't special as unsigned char while quoting the standard and referencing below Bugzilla bug. Another good article on strict aliasing: https://gustedt.wordpress.com/2016/08/17/effective-types-and-aliasing/ > I found these, but these are just discussions: > https://stackoverflow.com/questions/16138237/when-is-uint8-t-%E2%89%A0-unsigned-char > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66110 I like the Bugzilla link as it shows how some code benefits from uint8_t not having the same aliasing requirements as e.g. unsigned char. Thus, it's an example of why compiler developers might be motivated to decide against making uint8_t a typedef of unsigned char, since the standard doesn't require it. > What about rewording the sentence "uint8_t doesn't have the same > strict-aliasing properties as unsigned char" to clarify that unsigned > char may alias, but uint8_t may not? I can change "That means a superfluous cast is removed and aliasing through a uint8_t pointer is eliminated. Note that uint8_t doesn't have the same strict-aliasing properties as unsigned char." to "That means a superfluous cast is removed and aliasing through a uint8_t pointer is eliminated. NB: The C standard specifies that a unsigned char pointer may alias while the C standard doesn't include such requirement for uint8_t pointers." Better? Best regards Georg -- 'This function is not fully implemented in some standard libraries. For example, gcc and clang always return zero even though the device is non-deterministic. In comparison, Visual Studio always returns 32, and boost.random returns 10.' (http://en.cppreference.com/w/cpp/numeric/random/random_device/entropy, 2014)