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)
