hxhxhrra
Joined 8 years ago
Karma
67
Submissions
7
Member since
May 9
Recent submissions
Comment · 3 years ago
Maybe consider a different color palette. I have a red/green color blindness (like ~8% of the male population), and I can only barely differentiate the colors.
Comment · 4 years ago
I wouldn't call some cases of UB like overflowing a signed int or running into a dangling reference "actively pushing the compiler". I'm having a hard time believing you didn't ever run into these or similar issues having "programmed for a long time".
For other cases (e.g. aliasing, alignment), I'd agree that one is rather safe as long as the dangerous tools (e.g. reinterpret_cast) are not used.
Comment · 4 years ago
> I don't believe that it does. If the invalid arithmetic proceeds without crashing, and produces a value in the int32_t i variable, then that issue is settled. The subsequent statement should behave according to accessing that value.
You may dislike it, but that is not how UB in C and C++ works. See [1] for a guide to UB in C/C++ that may already have been posted elsewhere here.
It is a common misconception that UB on a particular operation means "undefined result", but that is not the case. UB means there are no constraints whatsoever on the behavior of the program after UB, often referred to as "may delete all your files". See [2] for a real-world demo doing that.
[1] https://blog.regehr.org/archives/213
[2] https://kristerw.blogspot.com/2017/09/why-undefined-behavior...
Comment · 4 years ago
As others are pointing out, the C standard does allow this.
There is no safe way to check for undefined behavior (UB) after it has happened, because the whole program is immediately invalidated.
This has caused a Linux kernel exploit in the past [1], with GCC removing a null pointer check after a pointer had been dereferenced. Null pointer dereferences are UB, thus GCC was allowed to remove the following check against null. In the kernel, accessing a null ptr is technically fine, so the Linux kernel is now compiled with -fno-delete-null-pointer-checks, extending the list of differences between standard C and Linux kernel C.
Comment · 6 years ago
Algorithm fib1 („Dynamic Programming without Memoization“) is just ordinary recursion and not dynamic programming.
Comment · 7 years ago
It is hard to overestimate the importance of the OEIS in enumerative combinatorics.
I discovered the main results of my PhD thesis essentially as follows:
1. Find complicated construction A, hoping to prove some new results.
2. Fail to sufficiently understand/analyze A.
3. Write computer program to analyze characteristics of A for small n.
4. Using OEIS, discover that apparently A is (in some sense) equivalent to some completely different construction B, which is much simpler and well-understood.
5. Show desired result as well as further other results using B and variations of it.
Comment · 7 years ago
This problem is called Chinese Postman Problem and can be solved in polynomial time using matching algorithms: