strict-aliasing

I've read this article about C/C++ strict aliasing . I think the same applies to C++. As I understand, strict aliasing is used to rearrange the code for performance optimization. That's why two pointers of different (and unrelated in C++ case) types cannot refer to the same memory location. Does this mean that problems can occur only if memory is modified? Apart of possible problems with memory alignment . For example, handling network protocol, or de-serialization. I have a byte array, dynamically allocated and packet struct is properly aligned. Can I reinterpret_cast it to my packet struct?

Consider the following scenario: std::array<int, 8> a; auto p = reinterpret_cast<int(*)[8]>(a.data()); (*p)[0] = 42; Is this undefined behavior ? I think it is. a.data() returns a int* , which is not the same as int(*)[8] The type aliasing rules on cppreference seem to suggest that the reinterpret_cast is not valid As a programmer, I know that the memory location pointed by a.data() is an array of 8 int objects Is there any rule I am missing that makes this reinterpret_cast valid? An array object and its first element are not pointer-interconvertible * , so the result of the reinterpret_cast

I'm trying to fix two warnings when compiling a specific program using GCC. The warnings are: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] and the two culprits are: unsigned int received_size = ntohl (*((unsigned int*)dcc->incoming_buf)); and *((unsigned int*)dcc->outgoing_buf) = htonl (dcc->file_confirm_offset); incoming_buf and outgoing_buf are defined as follows: char incoming_buf[LIBIRC_DCC_BUFFER_SIZE]; char outgoing_buf[LIBIRC_DCC_BUFFER_SIZE]; This seems subtly different than the other examples of that warning I've been examining. I

The Question The question of whether all pointers derived from pointers to structure types are the same, is not easy to answer. I find it to be a significant question for the following two primary reasons. A. The lack of a pointer to pointer to 'any' incomplete or object type, imposes a limitation on convenient function interfaces, such as: int allocate(ANY_TYPE **p, size_t s); int main(void) { int *p; int r = allocate(&p, sizeof *p); } [ Complete code sample ] The existing pointer to 'any' incomplete or object type is explicitly described as: C99 / C11 §6.3.2.3 p1 : A pointer to void may be

The context of my problem is in network programming. Say I want to send messages over the network between two programs. For simplicity, let's say messages look like this, and byte-order is not a concern. I want to find a correct, portable, and efficient way to define these messages as C structures. I know of four approaches to this: explicit casting, casting through a union, copying, and marshaling. struct message { uint16_t logical_id; uint16_t command; }; Explicit Casting: void send_message(struct message *msg) { uint8_t *bytes = (uint8_t *) msg; /* call to write/send/sendto here */ } void

Consider the following code ( p is of type unsigned char* and bitmap->width is of some integer type, exactly which is unknown and depends on which version of some external library we're using): for (unsigned x = 0; x < static_cast<unsigned>(bitmap->width); ++x) { *p++ = 0xAA; *p++ = 0xBB; *p++ = 0xCC; } Is it worth optimizing it [..] Could there be a case where this could yield more efficient results by writing: unsigned width(static_cast<unsigned>(bitmap->width)); for (unsigned x = 0; x < width; ++x) { *p++ = 0xAA; *p++ = 0xBB; *p++ = 0xCC; } ... or is this trivial for the compiler to

Often in embedded programming (but not limited to) there is a need to serialize some arbitrary struct in order to send it over some communication channel or write to some memory. Example Let's consider a structure composed of different data types in a N -aligned memory region: struct { float a; uint8_t b; uint32_t c; } s; Now let's assume we have a library function void write_to_eeprom(uint32_t *data, uint32_t len); which is taking the pointer to data to be written as a uint32_t* . Now we would like to write s to the eeprom using this function. A naive approach would be to do something like