3 ms·

It's moot to the aforementioned point. Undefined behavior wasn't introduced as a new language "feature" between C89 and C23; it's existed the whole time. We're

by deaddodo 11mo ago

It's moot to the aforementioned point. Undefined behavior wasn't introduced as a new language "feature" between C89 and C23; it's existed the whole time. We're talking about specification deltas, not the entire corpus. But, if you want an answer to your question: You can learn to avoid undefined behavior in about 30 seconds. If you're purposefully fiddling with undefined behavior, it's because (ideally) you're A) an advanced developer and you know exactly what you're trying to achieve (and inspecting the generated code) and/or B) you're using a specific compiler and don't plan on porting your code elsewhere.

rini17 11mo ago
Before you could assume signed arithmetic overflow will be whatever the CPU does, or null pointer derefs will be trapped by the OS. That is pretty big difference from what can happen now, moved C away from that "portable assembler" moniker so very not moot. Even if it was never explicitly standardized. > You can learn to avoid undefined behavior in about 30 seconds. Source? I mean, if it's really that simple then someone already compiled that 30 second advice and you can simply link it here for us. Ideally including examples how to actually do signed arithmetic safely. You can't avoid negative numbers lol.
- deaddodo 11mo ago
  [flagged]
  - dang 11mo ago
    Hey can you please not cross into personal attack? We're trying for something else here, and you can make your substantive points without that. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- jasomill 11mo ago
  Before you could assume...null pointer derefs will be trapped by the OS Before when? Microsoft(R) MS-DOS(R) Version 6.22 (C)Copyright Microsoft Corp 1981-1994. C:\TMP>type foo.c void main() { long q = 0; q = 0/q; } C:\TMP>cl /Od foo.c Microsoft (R) Optimizing Compiler Version 5.10 Copyright (C) Microsoft Corp 1984, 1985, 1986, 1987, 1988. All rights reserved. [...] C:\TMP>foo run-time error R6003 - integer divide by 0 C:\TMP>type bar.c void main() { long far *p = 0; long q = 0; *p = 0; q = 0/q; } C:\TMP>cl /Od bar.c [...] C:\TMP>bar (system hangs)
  - rini17 11mo ago
    In DOS you always had to manage your expectations, not sure what you're trying to prove here?

rini17 11mo ago

Before you could assume signed arithmetic overflow will be whatever the CPU does, or null pointer derefs will be trapped by the OS. That is pretty big difference from what can happen now, moved C away from that "portable assembler" moniker so very not moot. Even if it was never explicitly standardized. > You can learn to avoid undefined behavior in about 30 seconds. Source? I mean, if it's really that simple then someone already compiled that 30 second advice and you can simply link it here for us. Ideally including examples how to actually do signed arithmetic safely. You can't avoid negative numbers lol.

deaddodo 11mo ago
[flagged]
- dang 11mo ago
  Hey can you please not cross into personal attack? We're trying for something else here, and you can make your substantive points without that. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
jasomill 11mo ago
Before you could assume...null pointer derefs will be trapped by the OS Before when? Microsoft(R) MS-DOS(R) Version 6.22 (C)Copyright Microsoft Corp 1981-1994. C:\TMP>type foo.c void main() { long q = 0; q = 0/q; } C:\TMP>cl /Od foo.c Microsoft (R) Optimizing Compiler Version 5.10 Copyright (C) Microsoft Corp 1984, 1985, 1986, 1987, 1988. All rights reserved. [...] C:\TMP>foo run-time error R6003 - integer divide by 0 C:\TMP>type bar.c void main() { long far *p = 0; long q = 0; *p = 0; q = 0/q; } C:\TMP>cl /Od bar.c [...] C:\TMP>bar (system hangs)
- rini17 11mo ago
  In DOS you always had to manage your expectations, not sure what you're trying to prove here?