strict-aliasing | 易学教程

Can Aliasing Problems be Avoided with const Variables

阅读更多关于 Can Aliasing Problems be Avoided with const Variables

问题 My company uses a messaging server which gets a message into a const char* and then casts it to the message type. I've become concerned about this after asking this question. I'm not aware of any bad behavior in the messaging server. Is it possible that const variables do not incur aliasing problems? For example say that foo is defined in MessageServer in one of these ways: As a parameter: void MessageServer(const char* foo) Or as const variable at the top of MessageServer : const char* foo =

C99 strict aliasing rules in C++ (GCC)

阅读更多关于 C99 strict aliasing rules in C++ (GCC)

问题 As far as I understand, GCC supports all of its C99 features in C++. But how is C99 strict aliasing handled in C++ code? I know that casting with C casts between unrelated types is not strict-aliasing-safe and may generate incorrect code, but what about C++? Since strict aliasing is not part of C++ standard (is that correct?), GCC must be specifying the semantics itself. I figure const_cast and static_cast cast between related types, hence they are safe, while reinterpret_cast can break

Could we access member of a non-existing class type object?

阅读更多关于 Could we access member of a non-existing class type object?

问题 In the c++ standard, in [basic.lval]/11.6 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:[...] an aggregate or union type that includes one of the aforementioned types among its elements or non-static data members (including, recursively, an element or non-static data member of a subaggregate or contained union),[...] This sentence is part of the strict-aliasing rule. Does it allow us to

Shared memory buffers in C++ without violating strict aliasing rules

阅读更多关于 Shared memory buffers in C++ without violating strict aliasing rules

I am struggling with implementing a shared memory buffer without breaking C99's strict aliasing rules. Suppose I have some code that processes some data and needs to have some 'scratch' memory to operate. I could write it as something like: void foo(... some arguments here ...) { int* scratchMem = new int[1000]; // Allocate. // Do stuff... delete[] scratchMem; // Free. } Then I have another function that does some other stuff that also needs a scratch buffer: void bar(...arguments...) { float* scratchMem = new float[1000]; // Allocate. // Do other stuff... delete[] scratchMem; // Free. } The

C++'s Strict Aliasing Rule - Is the 'char' aliasing exemption a 2-way street?

阅读更多关于 C++'s Strict Aliasing Rule - Is the 'char' aliasing exemption a 2-way street?

问题 Just a couple weeks ago, I learned that the C++ Standard had a strict aliasing rule. Basically, I had asked a question about shifting bits -- rather than shifting each byte one at a time, to maximize performance I wanted to load my processor's native register's with (32 or 64 bits, respectively) and perform the shift of 4/8 bytes all in a single instruction. This is the code I wanted to avoid: unsigned char buffer[] = { 0xab, 0xcd, 0xef, 0x46 }; for (int i = 0; i < 3; ++i) { buffer[i] <<= 4;

Unions, aliasing and type-punning in practice: what works and what does not?

阅读更多关于 Unions, aliasing and type-punning in practice: what works and what does not?

问题 I have a problem understanding what can and cannot be done using unions with GCC. I read the questions (in particular here and here) about it but they focus the C++ standard, I feel there's a mismatch between the C++ standard and the practice (the commonly used compilers). In particular, I recently found confusing informations in the GCC online doc while reading about the compilation flag -fstrict-aliasing . It says: -fstrict-aliasing Allow the compiler to assume the strictest aliasing rules

Once again: strict aliasing rule and char*

阅读更多关于 Once again: strict aliasing rule and char*

问题 The more I read, the more confused I get. The last question from the related ones is closest to my question, but I got confused with all words about object lifetime and especially - is it OK to only read or not. To get straight to the point. Correct me if I'm wrong. This is fine, gcc does not give warning and I'm trying to "read type T ( uint32_t ) via char* ": uint32_t num = 0x01020304; char* buff = reinterpret_cast< char* >( &num ); But this is "bad" (also gives a warning) and I'm trying

Is it a strict aliasing violation to alias a struct as its first member?

阅读更多关于 Is it a strict aliasing violation to alias a struct as its first member?

Sample code: struct S { int x; }; int func() { S s{2}; return (int &)s; // Equivalent to *reinterpret_cast<int *>(&s) } I believe this is common and considered acceptable. The standard does guarantee that there is no initial padding in the struct. However this case is not listed in the strict aliasing rule (C++17 [basic.lval]/11): 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: (11.1) the dynamic type of the object, (11.2) a cv-qualified version of the dynamic type of the object, (11.3) a type

Is unsigned char a[4][5]; a[1][7]; undefined behavior?

阅读更多关于 Is unsigned char a[4][5]; a[1][7]; undefined behavior?

One of the examples of undefined behavior from the C standard reads (J.2): — An array subscript is out of range, even if an object is apparently accessible with the given subscript (as in the lvalue expression a[1][7] given the declaration int a[4][5]) (6.5.6) If the declaration is changed from int a[4][5] to unsigned char a[4][5] , does accessing a[1][7] still result in undefined behavior? My opinion is that it does not, but I have heard from others who disagree, and I'd like to see what some other would-be experts on SO think. My reasoning: By the usual interpretation of 6.2.6.1 paragraph 4,

Correct, portable way to interpret buffer as a struct

阅读更多关于 Correct, portable way to interpret buffer as a struct

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