6 ms·

> allow new C standards to change the way undefined behaviors are conceived, Of all the potential issues that might be attributed to C, undefined behavior (UB)

> allow new C standards to change the way undefined behaviors are conceived, Of all the potential issues that might be attributed to C, undefined behavior (UB) is the one that creates few to no problems at all. To me, complaining about UB is like complaining about the quality of a highway once they intentionally break through the guard rails and start racing through the middle of the woods. The reason why some behavior is intentionally left undefined is to enable implementations to do whatever they find best in a given platform. This is not a problem, it's a solution to whole classes of problems. https://en.wikipedia.org/wiki/Undefined_behavior https://en.wikipedia.org/wiki/Undefined_behavior

rhinoceraptor 7y ago
This is like saying there's nothing dangerous about guns, because it takes a human to make them dangerous. C is not unsafe if you only write safe code. But humans are fallible, and "just don't write unsafe code" is not a solution.
- rumanator 7y ago
  > This is like saying there's nothing dangerous about guns, because it takes a human to make them dangerous. If you want to go with that analogy, UB is a kin of you intentionally pointing your gun to your foot, taking your time to aim it precisely on your foot, and in spite of all the possible warnings and error messages that are shouted at you... You still decide that yes, what you want to do is to shoot yourself in the foot because that is exactly what you want to achieve. And then complain about the consequences.
  - masklinn 7y ago
    > If you want to go with that analogy, UB is a kin of you intentionally pointing your gun to your foot, taking your time to aim it precisely on your foot, and in spite of all the possible warnings and error messages that are shouted at you… Yeaaaah not really: #include <stdio.h> #include <stdlib.h> #include <string.h> static char a[128]; static char b[128]; int main(int argc, char *argv[]) { (void)argc; strcpy(a + atoi(argv[1]), "owned."); printf("%s\n", b); return 0; } compiles with no warning using clang (8), even with -Weverything And that’s a super easy case, it’s not a use after a dynamic callback somewhere freed a pointer it did not own, or a function 5 levels deep (or worse in a dll) didn’t check its input pointer which only became occasionally null years later.
    - deleted 7y ago
      [deleted]
    - saagarjha 7y ago
      And many (myself included) think that the compiler should not warn about this code, even if it can potentially exhibit undefined behavior, because it would make it impossible to write code at all without warnings. (A good static analyzer or code reviewer should call it out, though.)
      - masklinn 7y ago
        That's completely fair. I'm not criticising the compiler not complaining about this code, I'm providing a counter-point to rumanator's assertion that: > UB is a kin of you intentionally pointing your gun to your foot, taking your time to aim it precisely on your foot, and in spite of all the possible warnings and error messages that are shouted at you… Because they could hardly be more wrong, the average UB is completely invisible to static analysers because it's a dynamic condition which the type system is not smart enough to move to static. That's why it's an UB and not, say, a compile error.
  - rhinoceraptor 7y ago
    OpenBSD has almost a singular focus on security, and even they have vulnerabilities. If they can't write safe C 100% of the time, what hope does anyone else have?
    - yjftsjthsd-h 7y ago
      So... Is there an OS with zero vulnerabilities written in Rust/Go/Ada/anything that I should know about? If nobody's written safe Rust/Go/Ada/whatever 100% of the time, what hope do I have? Now, I think that particular argument is poor. The more defensible version would be to look at the proportion of errors that occurred in C that would not occur in your language of choice, versus the number of errors that occur in this other language that would be unlikely to occur in C. And for completeness it would be good to do some sort of evaluation as to whether they were other gotchas like performance of the resulting code and programmer productivity. I expect that in the grand scheme of things, C is not the best option, but 100% perfection is an absurd goal post and makes it a lot easier for people to dismiss your argument.
      - myrrlyn 7y ago
        Redox[0] actively wants to hear your vulnerability reports. [0]: https://www.redox-os.org/ https://www.redox-os.org/
        thesuperbigfrog 7y ago
        What hardware does it run on? I looked through the documentation and cannot find what hardware it runs on and how to set it up. The Getting Started for real hardware returns a 404 page: https://doc.redox-os.org/book/real_hardware.html https://doc.redox-os.org/book/real_hardware.html
      - pjmlp 7y ago
        Yes, Unisys ClearPath MCP, written in NEWP, a secure systems language 10 years older than C. It is still in use, because when governments want safety above anything else, they buy such OSes, not UNIX clones. https://www.unisys.com/offerings/clearpath-forward/clearpath-forward-products https://www.unisys.com/offerings/clearpath-forward/clearpath...
anarazel 7y ago
Implementation defined behaviour is not the same as undefined behavior.
- sweeneyrod 7y ago
  And unspecified behaviour is (slightly) different again.
pdimitar 7y ago
While this is the ideal theory I think we've all seen how it simply doesn't pan out in practice. The numerous and regular terrifying security bugs that are being found in ancient tools (some 30+ years old) are a living testament that the philosophy you quoted just doesn't translate that well into the reality of humans programming the current breed of computers. Hence the existence of languages like Rust and the recent general strive towards more correctness and more compile-time catching of potential problems (especially in light of GCC 10's new `-fanalyzer` flag).
antirez 7y ago
All the other low level stuff of C can be handled by a professional programmer in different ways, using tools like Valgrind, with careful coding, but especially with higher order libraries, so you don't have to write much low level code. Any language is dangerous and bug prone if the standard library has no dynamic strings and basic data structures. If you have the right tools, C becomes a lot more high level, a lot more safe, and has a long story of solving very important problems reliably and in a portable way.
- camgunz 7y ago
  Yeah I agree. But even more than that, I think a lot of people would like to overlook that programming is fundamentally unsafe. Even if you're working in a safe language, that language's runtime is almost certainly in an unsafe language, making syscalls through a library written in an unsafe language, interacting with an OS written in an unsafe language, interacting with hardware running on firmware written in an unsafe language. Sure there should be a boundary somewhere. But whether that boundary should be a type system or valgrind/cppcheck/etc. differs case-by-case.
namibj 7y ago
Your wording only works for "implementation defined", not "undefined". Both exist in the standard, and the former is quite sane to use. E.g., on any normal architecture, specifying signed integer overflow to be implementation defined would have been great, though on e.g. the JS-style machine that abuses IEEE floats in limited range as integers, addition get's weird once the point floats to the left of where you'd normally write it by hand (in non-scientific notation). y = x; x += 1; x -= 1; true == (x != y); But I don't know of any actual integer machine that would want integer overflow to actually be UB.
jerf 7y ago
"like complaining about the quality of a highway once they intentionally break through the guard rails" Your metaphor brings to mind an image of someone who can see the guard rail, and then deliberately chooses to expend quite non-trivial effort to break them. This is not an accurate metaphor. As I'm not in the metaphor fix-up business, because I believe they tend to mess us up in precisely this sort of way, let me simply directly point out this gets it backwards. The default is that you will write a program shot through with undefined behavior, and you must make quite substantial, intellectually-challenging efforts above and beyond the intellectual challenge of writing something in C at all that at least sometimes works, to write your program in a way that doesn't have UB in it. It has no resemblance to driving down a road in a normal fashion and then bashing guard rails down.
adrianN 7y ago
What happens when you reach outside of an array or access memory after it was freed falls under UB and those are the most serious problems about the C family of languages.
naasking 7y ago
> To me, complaining about UB is like complaining about the quality of a highway once they intentionally break through the guard rails and start racing through the middle of the woods. Sure, if those guardrails are 1mm tall and so barely visible, then that's a valid analogy to C. I hope you can see why this is not an ergonomic design that will lead to safe programs (or safe highways).

rhinoceraptor 7y ago

This is like saying there's nothing dangerous about guns, because it takes a human to make them dangerous. C is not unsafe if you only write safe code. But humans are fallible, and "just don't write unsafe code" is not a solution.

rumanator 7y ago
> This is like saying there's nothing dangerous about guns, because it takes a human to make them dangerous. If you want to go with that analogy, UB is a kin of you intentionally pointing your gun to your foot, taking your time to aim it precisely on your foot, and in spite of all the possible warnings and error messages that are shouted at you... You still decide that yes, what you want to do is to shoot yourself in the foot because that is exactly what you want to achieve. And then complain about the consequences.
- masklinn 7y ago
  > If you want to go with that analogy, UB is a kin of you intentionally pointing your gun to your foot, taking your time to aim it precisely on your foot, and in spite of all the possible warnings and error messages that are shouted at you… Yeaaaah not really: #include <stdio.h> #include <stdlib.h> #include <string.h> static char a[128]; static char b[128]; int main(int argc, char *argv[]) { (void)argc; strcpy(a + atoi(argv[1]), "owned."); printf("%s\n", b); return 0; } compiles with no warning using clang (8), even with -Weverything And that’s a super easy case, it’s not a use after a dynamic callback somewhere freed a pointer it did not own, or a function 5 levels deep (or worse in a dll) didn’t check its input pointer which only became occasionally null years later.
  - deleted 7y ago
    [deleted]
  - saagarjha 7y ago
    And many (myself included) think that the compiler should not warn about this code, even if it can potentially exhibit undefined behavior, because it would make it impossible to write code at all without warnings. (A good static analyzer or code reviewer should call it out, though.)
    - masklinn 7y ago
      That's completely fair. I'm not criticising the compiler not complaining about this code, I'm providing a counter-point to rumanator's assertion that: > UB is a kin of you intentionally pointing your gun to your foot, taking your time to aim it precisely on your foot, and in spite of all the possible warnings and error messages that are shouted at you… Because they could hardly be more wrong, the average UB is completely invisible to static analysers because it's a dynamic condition which the type system is not smart enough to move to static. That's why it's an UB and not, say, a compile error.
- rhinoceraptor 7y ago
  OpenBSD has almost a singular focus on security, and even they have vulnerabilities. If they can't write safe C 100% of the time, what hope does anyone else have?
  - yjftsjthsd-h 7y ago
    So... Is there an OS with zero vulnerabilities written in Rust/Go/Ada/anything that I should know about? If nobody's written safe Rust/Go/Ada/whatever 100% of the time, what hope do I have? Now, I think that particular argument is poor. The more defensible version would be to look at the proportion of errors that occurred in C that would not occur in your language of choice, versus the number of errors that occur in this other language that would be unlikely to occur in C. And for completeness it would be good to do some sort of evaluation as to whether they were other gotchas like performance of the resulting code and programmer productivity. I expect that in the grand scheme of things, C is not the best option, but 100% perfection is an absurd goal post and makes it a lot easier for people to dismiss your argument.
    - myrrlyn 7y ago
      Redox[0] actively wants to hear your vulnerability reports. [0]: https://www.redox-os.org/ https://www.redox-os.org/
      - thesuperbigfrog 7y ago
        What hardware does it run on? I looked through the documentation and cannot find what hardware it runs on and how to set it up. The Getting Started for real hardware returns a 404 page: https://doc.redox-os.org/book/real_hardware.html https://doc.redox-os.org/book/real_hardware.html
    - pjmlp 7y ago
      Yes, Unisys ClearPath MCP, written in NEWP, a secure systems language 10 years older than C. It is still in use, because when governments want safety above anything else, they buy such OSes, not UNIX clones. https://www.unisys.com/offerings/clearpath-forward/clearpath-forward-products https://www.unisys.com/offerings/clearpath-forward/clearpath...

anarazel 7y ago

Implementation defined behaviour is not the same as undefined behavior.

sweeneyrod 7y ago
And unspecified behaviour is (slightly) different again.

pdimitar 7y ago

While this is the ideal theory I think we've all seen how it simply doesn't pan out in practice. The numerous and regular terrifying security bugs that are being found in ancient tools (some 30+ years old) are a living testament that the philosophy you quoted just doesn't translate that well into the reality of humans programming the current breed of computers. Hence the existence of languages like Rust and the recent general strive towards more correctness and more compile-time catching of potential problems (especially in light of GCC 10's new `-fanalyzer` flag).

antirez 7y ago

All the other low level stuff of C can be handled by a professional programmer in different ways, using tools like Valgrind, with careful coding, but especially with higher order libraries, so you don't have to write much low level code. Any language is dangerous and bug prone if the standard library has no dynamic strings and basic data structures. If you have the right tools, C becomes a lot more high level, a lot more safe, and has a long story of solving very important problems reliably and in a portable way.

camgunz 7y ago
Yeah I agree. But even more than that, I think a lot of people would like to overlook that programming is fundamentally unsafe. Even if you're working in a safe language, that language's runtime is almost certainly in an unsafe language, making syscalls through a library written in an unsafe language, interacting with an OS written in an unsafe language, interacting with hardware running on firmware written in an unsafe language. Sure there should be a boundary somewhere. But whether that boundary should be a type system or valgrind/cppcheck/etc. differs case-by-case.

namibj 7y ago

Your wording only works for "implementation defined", not "undefined". Both exist in the standard, and the former is quite sane to use. E.g., on any normal architecture, specifying signed integer overflow to be implementation defined would have been great, though on e.g. the JS-style machine that abuses IEEE floats in limited range as integers, addition get's weird once the point floats to the left of where you'd normally write it by hand (in non-scientific notation). y = x; x += 1; x -= 1; true == (x != y); But I don't know of any actual integer machine that would want integer overflow to actually be UB.

jerf 7y ago

"like complaining about the quality of a highway once they intentionally break through the guard rails" Your metaphor brings to mind an image of someone who can see the guard rail, and then deliberately chooses to expend quite non-trivial effort to break them. This is not an accurate metaphor. As I'm not in the metaphor fix-up business, because I believe they tend to mess us up in precisely this sort of way, let me simply directly point out this gets it backwards. The default is that you will write a program shot through with undefined behavior, and you must make quite substantial, intellectually-challenging efforts above and beyond the intellectual challenge of writing something in C at all that at least sometimes works, to write your program in a way that doesn't have UB in it. It has no resemblance to driving down a road in a normal fashion and then bashing guard rails down.

adrianN 7y ago

What happens when you reach outside of an array or access memory after it was freed falls under UB and those are the most serious problems about the C family of languages.

naasking 7y ago

> To me, complaining about UB is like complaining about the quality of a highway once they intentionally break through the guard rails and start racing through the middle of the woods. Sure, if those guardrails are 1mm tall and so barely visible, then that's a valid analogy to C. I hope you can see why this is not an ergonomic design that will lead to safe programs (or safe highways).