undefined-behavior

问题 Recently I've discovered that sometimes being able to turn rvalues temporarily into lvalues can be useful for me. I've been using the following tool: #include <type_traits> template <typename T> inline constexpr std::remove_reference_t<T> &lvalue(T &&r) noexcept { return static_cast<std::remove_reference_t<T> &>(r); } It's useful when you have to use functions that require lvalues as arguments, but you don't have any interest in what those particular values get changed into. For when you are

问题 int *p; { int x = 0; p = &x; } // p is no longer valid { int x = 0; if (&x == p) { *p = 2; // Is this valid? } } Accessing a pointer after the thing it points to has been freed is undefined behavior, but what happens if some later allocation happens in the same area, and you explicitly compare the old pointer to a pointer to the new thing? Would it have mattered if I cast &x and p to uintptr_t before comparing them? (I know it's not guaranteed that the two x variables occupy the same spot. I

问题 This question already has answers here : Can code that will never be executed invoke undefined behavior? (9 answers) Closed last year . Consider void swap(int* a, int* b) { if (a != b){ *a = *a ^ *b; *b = *a ^ *b; *a = *a ^ *b; } } int main() { int a = 0; int b = 1; swap(&a, &b); // after this b is 0 and a is 1 return a > b ? 0 : a / b; } swap is an attempt to fool the compiler into not optimising out the program. Is the behaviour of this program defined? a / b is never reachable, but if it

问题 As answered elsewhere, calling functions like memcpy with invalid or NULL pointers is undefined behaviour, even if the length argument is zero. In the context of such a function, especially memcpy and memmove , is a pointer just past the end of the array a valid pointer? I'm asking this question because a pointer just past the end of an array is legal to obtain (as opposed to, e.g. a pointer two elements past the end of an array) but you are not allowed to dereference it, yet footnote 106 of

问题 There are several interesting questions raised here regarding undefined behaviour in C. One of them is (slightly modified) Does the following piece of code result in undefined behaviour? int i = 0, *a = &i; // Line 1 a[i] = i + 1; // Line 2 Since there is no concrete answer to this part of the question there, and I am interested in knowing the behaviour in C++, I am raising it again here. Rule #2 from Undefined Behavior and Sequence Points says Furthermore, the prior value shall be accessed

问题 In my code I have effectively the following: wchar_t* buffer = new wchar_t[size]; // bonus irrelevant code here delete[] reinterpret_cast<char*>( buffer ); Types in question are all built-in and so they have trivial destructors. In VC++ the code above works allright - new[] just allocates memory, then delete[] just frees it. Is it acceptable in C++? Is it undefined behaviour? 回答1: My initial thought was that it is undefined behavior. 5.3.5/3: "In the second alternative ( delete array ) if the

问题 I have the following code FRAME frameArray[5][10]; // Create the array of frames int trackBufferFull[5] = {0, 0, 0, 0, 0};// Keeps track of how full the buffer for each node is int trackFront[5] = {0, 0, 0, 0, 0}; // Array to keep track of which is the front of the array int trackTail[5] = {0, 0, 0, 0, 0}; // Function to add to the array (CHANGE int frame) void addFrame (int nodeNumber, FRAME frame) { //Calc tail int tail = trackTail[nodeNumber-1]; // Calc frames in buffer int framesinBuffer

问题 Below code is dealing with a TYPE* const pointer. struct D { void Check () { D* const p = new D; // 2nd test is "p = 0;" cout<<"p = "<<p<<endl; (D*&)p = new D; cout<<"p = "<<p<<endl; // prints 0, "p = 0;" at declaration } }; int main () { D o; o.Check(); } My questions are, If you initialize with 0 , then even though typecasting next time will not work. Is doing such typecasting is undefined behavior ? this pointer is also of TYPE* const type, then why compiler doesn't allow the same

问题 I'm confused by something I read in the Shift Operators section of an article on undefined C++ behavior. On the ARM architecture, the shift operators always behave as if they take place in a 256-bit pattern space, regardless of the operand size--that is, the pattern repeats, or "wraps around", only every 256 positions. Another way of thinking of this is that the pattern is shifted the specified number of positions modulo 256. Then, of course, the result contains just the least-significant

问题 Somewhere in my code I am doing something very bad. I'm getting undefined behavior in my extrema variable when it does run but most of the time it doesn't even run. Any help would be really great. #include <stdio.h> void get_extrema(int quadrant, int **extrema) { if (quadrant == 1) { *(extrema)[0] = 0; *(extrema)[1] = 90; } else if (quadrant == 2) { *(extrema)[0] = -90; *(extrema)[1] = 0; } } void print(int* arr) { printf("%i",arr[0]); printf(","); printf("%i\n",arr[1]); } int main(void) {