3 ms·

It's still deterministic. It doesn't randomly do something different with the exact same IO. Just because it's hard to recreate the exact same state with concur

It's still deterministic. It doesn't randomly do something different with the exact same IO. Just because it's hard to recreate the exact same state with concurrent processes on a modern CPU doesn't change it's determinism. Also, undefined behavior in C only means a compiler can do what ever it likes. It doesn't make it random. People need to stop pretending UB in C is magic. It's not going to delete your hard disk, or make you a pizza unless that's already part of your program. GARBREPLEDFAH.../rant

MaxBarraclough 6y ago
Sure, but in both cases, the way to model it is with something like nondeterminism. Computers have no nondeterminism, but computer science does. Formally verified C code is guaranteed to be free of UB, as this is necessary in order for there to be guarantees about the behaviour of a program written in standard C. The underlying compiler and hardware are still deterministic. A similar thing happens with concurrency. > People need to stop pretending UB in C is magic. It's not going to delete your hard disk, or make you a pizza unless that's already part of your program. It probably won't delete your hard-disk, but complacency with UB is still a bad idea. C is a strange language. UB is permitted to travel back in time. [0] Even in the absence of UB, the optimiser is permitted (but not obligated) to eliminate empty infinite loops, so even a basic property like whether your program will ever terminate, may be up to the whims of the optimiser. [1] Anyway that was a long way of saying I agree, computers are deterministic, but something akin to nondeterminism can happen in the abstractions we use. [0] https://stackoverflow.com/a/39915175/ https://stackoverflow.com/a/39915175/ [1] https://news.ycombinator.com/item?id=13640636 https://news.ycombinator.com/item?id=13640636
- grayhatter 6y ago
  That's exactly what I mean about UB in C. I mean I agree with you If you don't know exactly what your compiler will do with the UB, (or if you ever might want to use a different compiler and or comp options) you probably want to avoid writing any UB. But it's not magic, and it can't time travel. That segment makes explicit that UB doesn't need to create a sequence point around UB. This is important because if it did need to do that (to protect the non-UB code) the compiler would need to keep a list of all UB. I'm pretty sure that if you're going to create a list of all undefined behavior, you might as well just define it. It's not magic, it's just allowing the compiler to YOLO it, using optimizations it already knows how to do. I have a really cool example of how/why this is actually a good thing for compilers if you're interested.
deleted 6y ago
[deleted]

MaxBarraclough 6y ago

Sure, but in both cases, the way to model it is with something like nondeterminism. Computers have no nondeterminism, but computer science does. Formally verified C code is guaranteed to be free of UB, as this is necessary in order for there to be guarantees about the behaviour of a program written in standard C. The underlying compiler and hardware are still deterministic. A similar thing happens with concurrency. > People need to stop pretending UB in C is magic. It's not going to delete your hard disk, or make you a pizza unless that's already part of your program. It probably won't delete your hard-disk, but complacency with UB is still a bad idea. C is a strange language. UB is permitted to travel back in time. [0] Even in the absence of UB, the optimiser is permitted (but not obligated) to eliminate empty infinite loops, so even a basic property like whether your program will ever terminate, may be up to the whims of the optimiser. [1] Anyway that was a long way of saying I agree, computers are deterministic, but something akin to nondeterminism can happen in the abstractions we use. [0] https://stackoverflow.com/a/39915175/ https://stackoverflow.com/a/39915175/ [1] https://news.ycombinator.com/item?id=13640636 https://news.ycombinator.com/item?id=13640636

grayhatter 6y ago
That's exactly what I mean about UB in C. I mean I agree with you If you don't know exactly what your compiler will do with the UB, (or if you ever might want to use a different compiler and or comp options) you probably want to avoid writing any UB. But it's not magic, and it can't time travel. That segment makes explicit that UB doesn't need to create a sequence point around UB. This is important because if it did need to do that (to protect the non-UB code) the compiler would need to keep a list of all UB. I'm pretty sure that if you're going to create a list of all undefined behavior, you might as well just define it. It's not magic, it's just allowing the compiler to YOLO it, using optimizations it already knows how to do. I have a really cool example of how/why this is actually a good thing for compilers if you're interested.

deleted 6y ago

[deleted]