strict-aliasing

My understanding is that the following code has undefined behaviour in C++ due to something called "strict aliasing rule". #include <cstdint> enum Foo : int16_t {}; void test(Foo& foo) { reinterpret_cast<int16_t&>(foo) = 42; } In particular, a C++ compiler may omit the assignment altogether because it is allowed to assume that the int16_t& returned by the reinterpret_cast doesn't point to the same memory as foo (of type Foo& ) because their types are different. My question is, does Rust have something akin to the C++ "strict aliasing rule"? In other words, does the following, equivalent Rust

Im asking my self, can i use the BSD sockets with strict aliasing on, without getting undefined behaviour by compiling with gcc? bind(sdListen, (struct sockaddr*)&sockaddr_inIdentifier, sizeof(sockaddr_inIdentifier)) This line of code breaks the strict aliasing rule as far as i know (and gcc gives me the same warning). so is there a plan b, of using the sockets in O3 mode without turning strictaliasing of? And of course without breaking the rule? or do i have to get an own socket system running that will be runnable on all systems/compilers? The cast itself in that line does not break the

With these definitions: struct My_Header { uintptr_t bits; } struct Foo_Type { struct My_Header header; int x; } struct Foo_Type *foo = ...; struct Bar_Type { struct My_Header header; float x; } struct Bar_Type *bar = ...; Is it correct to say that this C code ( "case one" ): foo->header.bits = 1020; ...is actually different semantically from this code ( "case two" ): struct My_Header *alias = &foo->header; alias->bits = 1020; My understanding is that they should be different: Case One considers the assignment unable to affect the header in a Bar_Type. It only is seen as being able to

Consider the following code on a platform where the ABI does not insert padding into unions: union { int xi; } x; x.xi = 1; I believe that the second line exhibits undefined behaviour as it violates the strict aliasing rule: The object referred to by x.xi is the same object as the object referred to by x . Both are the same region of storage and the term object is defined in ISO 9899:2011 §3.15 as: object 1 region of data storage in the execution environment, the contents of which can represent values 2 NOTE When referenced, an object may be interpreted as having a particular type; see 6.3.2.1

I have a struct X which inherits from struct Base. However, in my current setup, due to alignment, size of X is 24B: typedef struct { double_t a; int8_t b; } Base; typedef struct { Base base; int8_t c; } X; In order to save the memory, I'd like to unwind the Base struct, so I created struct Y which contains fields from Base (in the same order, always at the beginning of the struct), so the size of the struct is 16B: typedef struct { double_t base_a; int8_t base_b; int8_t c; } Y; Then I'm going to use instance of struct Y in a method which expects a pointer to Base struct: void print_base(Base*

I'm trying to build a class template that packs a bunch of types in a suitably large char array, and allows access to the data as individual correctly typed references. Now, according to the standard this can lead to strict-aliasing violation, and hence undefined behavior, as we're accessing the char[] data via an object that is not compatible with it. Specifically, the standard states: If a program attempts to access the stored value of an object through a glvalue of other than one of the following types the behavior is undefined: the dynamic type of the object, a cv-qualified version of the