strict-aliasing

问题 Rust has strict aliasing rules. But can I work around them if "I know what I'm doing"? I'm trying to convert to Rust a C function that performs a complicated operation by reading from input buffer and writing to a destination buffer, but it has a clever optimization that allows the input and output buffer to be the same: foo(src, dst); // result is written to dst foo(buf, buf); // legal in C, does the operation in-place For the sake of the question let's say it's something like: void inplace

问题 Reading this I understood that you can alias structures (without violating the standard, that is) if they have compatible members, i.e given the following struct: typedef struct { uint32_t a; uint32_t b; } Frizzly; The following would break aliasing rules: uint32_t foo(uint16_t *i) { Frizzly *f = (Frizzly *)i; return f->a; } But the following would not: uint32_t foo(uint32_t *i) { Frizzly *f = (Frizzly *)i; return f->b; } because the "aggregrate type" in question contains types compatible

问题 Is it good practice to access a pointer variable by dereferencing a pointer to a pointer, which points to a different type or void ? Could this break strict aliasing rules? C and C++ have some differences in aliasing rules. In this question we focus on C++. The other question considering C can be found here. In the following example a double* is accessed as a void* . int create_buffer(void** ptr, ...) { *ptr = malloc(...); ... } int main(void) { double* buffer; // The problematic code is here

问题 The strict aliasing rule says 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 dynamic type of the object, — a type similar (as defined in 4.4) to the dynamic type of the object, — a type that is the signed or unsigned type corresponding to the dynamic type of the object, — a type that is the signed or unsigned type corresponding

问题 Does it violate strict aliasing rules to move items of any type around using uint32_t, then read them back? If so, does it also violate strict aliasing rules to memcpy from an array of uint32_ts to an array of any type, then read the elements back? The following code sample demonstrates both cases: #include <assert.h> #include <stdio.h> #include <stdint.h> #include <string.h> int main(void) { const char *strings[5] = { "zero", "one", "two", "three", "four" }; uint32_t buffer[5]; int i; assert

问题 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

问题 I know that reinterpret_cast is primarily used going to or from a char* . But I was surprised to find that static_cast could do the same with a void* . For example: auto foo "hello world"s; auto temp = static_cast<void*>(&foo); auto bar = static_cast<string*>(temp); What do we gain from using reinterpret_cast and char* over static_cast and void* ? Is it something to do with the strict aliasing problem? 回答1: Generally speaking, static_cast will do cast any two types if one of them can be cast

问题 Is the following a standards-compliant C program (and by which standard(s))? If it is non-compliant (by breaking the strict aliasing rule or otherwise) is it "safe" with respect to GCC or any other commonly-used C compiler? int main() { typedef struct { int data; } Type1; typedef struct { float data; } Type2; typedef struct { Type1 type1; Type2 type2; } Aggregate; Aggregate aggregate; aggregate.type1.data = 1; aggregate.type2.data = 2.0; Aggregate *p_aggegregate = &aggregate; Type1 *p_type1 =

问题 I wonder if it is possible to tailor strict aliasing requirements to specifically designed cases, while still preserving strict aliasing in general or -O2/-O3 optimization respectively. To be more precise, in cases where it is needed, strict aliasing can be bypassed using an anonymous union (as pointed out here and here): #define PTR_CAST(type, x) &(((union {typeof(*x) src; type dst;}*) &(x))->dst) Now I wonder if using __restrict on a pointer obtained by such a cast would re-enable no-alias

问题 If we have an array within a struct: struct Names { uint8 fileId; uint8 name[50]; }; and then we try to assign a uint16 from the array to a uint16 variable like: uint16 someName = *((uint16 *)&NamesObj.name[21]); Will this violate aliasing rule/alignment rules and lead to undefined behaviour? 回答1: Yes, this violates C rules. The objects in name are uint8 (presumably some unsigned 8-bit integer type), and they are accessed through a pointer to uint16 (presumably some 16-bit integer type). The