Timeline for C++ and memory safety
Current License: CC BY-SA 4.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 19, 2024 at 10:03 | comment | added | freakish | @gnasher729 concrete behaviour of integer overflow depends on its representation. I'm pretty sure almost all, if not all, modern cpus use two's complement representation. And therefore the behaviour is de facto well defined. To the point that other languages (e.g. Rust) make it standard. C/C++ doesn't only for historical reasons. | |
| Sep 15, 2024 at 11:17 | comment | added | ojs | @gnasher729 you're right that signed integer overflow works like that on many machines. What UB means is that it might do something completely different at any unpredictable time. Including crashing right there, or producing almost correct results until crashing at some unpredictable time later. Have fun debugging the latter one. | |
| Sep 15, 2024 at 0:02 | comment | added | gnasher729 | INT_MAX+1 in C or C++ produces INT_MIN on many machines without crashing and the application works just fine. Or testing would have found a problem. So better than a crash. | |
| Sep 14, 2024 at 17:51 | comment | added | freakish | UB is much worse than crash. Consider reading data out of an array's range by mistake. Typically it won't crash, since there is some data there, often accessible to the process. This might even pass tests, and yet it may have a very unexpected and unwanted behaviour in production. And this particular example is a source of insane number of security vulnerabilities. | |
| Sep 3, 2024 at 7:23 | comment | added | Hans Olsson | What is worse sort of depends, a crash may also give worse outcome than UB. Consider Ariane 5 - instead of getting undefined values for a float to short integer conversion the program crashed, and brought the rocket down with it. But in general they are "equally bad" (or at least unacceptably bad) in critical situations. | |
| Jun 18, 2024 at 10:44 | history | edited | gnasher729 | CC BY-SA 4.0 |
added 75 characters in body
|
| Jun 17, 2024 at 16:33 | comment | added | Ccm | If safety is so important for OP, UB and crash are probably equally bad | |
| Jun 17, 2024 at 10:10 | comment | added | Basilevs | @amon is correct to point out, that UB is less acceptable than crash. UB is much more dangerous specifically because it sometimes does not lead to crash. In other words, there are a lot of situations where crash is acceptable while UB is not. | |
| Jun 16, 2024 at 23:45 | history | edited | gnasher729 | CC BY-SA 4.0 |
added 141 characters in body
|
| Jun 16, 2024 at 23:43 | comment | added | gnasher729 | “Guaranteed to crash” is in many situations unacceptable. Just like undefined behaviour, which in many cases is exactly the same. | |
| Jun 15, 2024 at 8:31 | comment | added | amon | I don't think this is a helpful take. Memory-safe languages don't magically make code correct, you're right on that. But "the program is guaranteed to crash" is much safer than UB, and at least gives you a decent chance to notice the problem. | |
| Jun 15, 2024 at 8:02 | history | answered | gnasher729 | CC BY-SA 4.0 |