4 ms·

Undefined behaviour actually isn't the monster that most C language lawyers want you to believe it is. With tools like valgrind, address sanitizers and modern d

Undefined behaviour actually isn't the monster that most C language lawyers want you to believe it is. With tools like valgrind, address sanitizers and modern debugging toolchains, most of these issues can be caught. Compilers are also mature enough to issue warnings about the use of uninitialized variables, missing return statements or mismatched printf specifiers. Heck, Clang maybe has more than 250 -W options.

junke 10y ago
Are you sure you aren't mixing causes and consequences? I'd say that this is actually because undefined behaviour is hard (didn't say impossible) to get right at the human level that tools were, and still are, being developed.
- ArkyBeagle 10y ago
  UB and IB ( implementation-defined ) have not been a problem for me for a couple decades now. No advocacy here - I started using C because it was about all there was - but it's just a learning curve. There was no direct cost to me because I was getting paid to learn this stuff on the job.
deleted 10y ago
[deleted]
pcwalton 10y ago
In theory, a good fraction of these can be caught. In practice, these issues keep coming up in production again and again and again.
- bluetomcat 10y ago
  Knowing your tools and compiler switches is key. The reward is that the final production code can be very lean and performant, without any runtime penalties to provide safety. Most people who complain about the dangers of C probably have used it in an unprofessional setting without any additional tooling. It's a bit like saying that all RWD cars are dangerous just because you've once driven a '92 BMW, disregarding any technological advancements since.
  - pcwalton 10y ago
    > Most people who complain about the dangers of C probably have used it in an unprofessional setting without any additional tooling. It's a bit like saying that all RWD cars are dangerous just because you've once driven a '92 BMW, disregarding any technological advancements since. Actually, most of the people I know who think C is a problem that needs fixing are longtime professional compiler developers and people who work on security critical codebases. In fact, I don't know any compiler engineers who don't have serious reservations about C and C++. Those people know more about tooling and instrumentation than virtually anybody. It's precisely that knowledge that leads one rapidly to the conclusion that there are serious flaws in C for secure software that can't just be papered over with tooling. It's usually C++ enthusiasts who are the ones trying (unsuccessfully, IMO) to argue that undefined behavior isn't a problem in practice.
anon1385 10y ago
>Compilers are also mature enough to issue warnings about the use of uninitialized variables That depends on the compiler. It's not true with GCC: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501
prodigal_erik 10y ago
Any user action that you didn't have a test case for can provoke catastrophic UB that valgrind never saw, so catching most issues has almost no value. This is why every OS and every app I have ever used were always unreliable shit.
ph14nix 10y ago
> With tools like valgrind, address sanitizers and modern debugging toolchains, most of these issues can be caught. Most of these tools require support from an operating system. This is not the case when you do kernel programming. For some reason even existing tools are not popular among kernel programmers [0]. IMO, there are bugs that can be caught well a compile time without my effort, so why should I waste time on catching them at runtime? I would better make love to compiler instead of having sex with debugger. [0] http://lwn.net/2000/0914/a/lt-debugger.php3 http://lwn.net/2000/0914/a/lt-debugger.php3

junke 10y ago

Are you sure you aren't mixing causes and consequences? I'd say that this is actually because undefined behaviour is hard (didn't say impossible) to get right at the human level that tools were, and still are, being developed.

ArkyBeagle 10y ago
UB and IB ( implementation-defined ) have not been a problem for me for a couple decades now. No advocacy here - I started using C because it was about all there was - but it's just a learning curve. There was no direct cost to me because I was getting paid to learn this stuff on the job.

deleted 10y ago

[deleted]

pcwalton 10y ago

In theory, a good fraction of these can be caught. In practice, these issues keep coming up in production again and again and again.

bluetomcat 10y ago
Knowing your tools and compiler switches is key. The reward is that the final production code can be very lean and performant, without any runtime penalties to provide safety. Most people who complain about the dangers of C probably have used it in an unprofessional setting without any additional tooling. It's a bit like saying that all RWD cars are dangerous just because you've once driven a '92 BMW, disregarding any technological advancements since.
- pcwalton 10y ago
  > Most people who complain about the dangers of C probably have used it in an unprofessional setting without any additional tooling. It's a bit like saying that all RWD cars are dangerous just because you've once driven a '92 BMW, disregarding any technological advancements since. Actually, most of the people I know who think C is a problem that needs fixing are longtime professional compiler developers and people who work on security critical codebases. In fact, I don't know any compiler engineers who don't have serious reservations about C and C++. Those people know more about tooling and instrumentation than virtually anybody. It's precisely that knowledge that leads one rapidly to the conclusion that there are serious flaws in C for secure software that can't just be papered over with tooling. It's usually C++ enthusiasts who are the ones trying (unsuccessfully, IMO) to argue that undefined behavior isn't a problem in practice.

anon1385 10y ago

>Compilers are also mature enough to issue warnings about the use of uninitialized variables That depends on the compiler. It's not true with GCC: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501

prodigal_erik 10y ago

Any user action that you didn't have a test case for can provoke catastrophic UB that valgrind never saw, so catching most issues has almost no value. This is why every OS and every app I have ever used were always unreliable shit.

ph14nix 10y ago

> With tools like valgrind, address sanitizers and modern debugging toolchains, most of these issues can be caught. Most of these tools require support from an operating system. This is not the case when you do kernel programming. For some reason even existing tools are not popular among kernel programmers [0]. IMO, there are bugs that can be caught well a compile time without my effort, so why should I waste time on catching them at runtime? I would better make love to compiler instead of having sex with debugger. [0] http://lwn.net/2000/0914/a/lt-debugger.php3 http://lwn.net/2000/0914/a/lt-debugger.php3