4 ms·

That C code is bad and doesn't compile on macOS using clang without adding #include <assert.h> . Just looking at it you can see the bugs. But the main problem I

That C code is bad and doesn't compile on macOS using clang without adding #include <assert.h> . Just looking at it you can see the bugs. But the main problem I'm having with this article is comparing a contrived C program with no tooling to Rust. As the author notes returning a stack address is caught by clang. Also simply compiling with address sanitizer or running under Valgrind would have caught the rest of the bugs. I'm not saying Rust isn't safer than C or not a sweet and useful language it is those things. What I am saying is comparing Rust to C without all the tooling that Modern C developers use is kind of disingenuous.

jstimpfle 9y ago
I don't even use any tooling except occasionally a debugger (gdb on Linux / Visual studio on Windows). I have spent more than 500 hours of the last 8 months in C (no complicated data structures), and I'm pretty sure I've spent less than 2 hours total tracing memory bugs. (not saying there aren't more hidden).
- 2trill2spill 9y ago
  Use as many tools as your platform supports. I've had "stable" C code run just fine for two years but come crashing to a halt immediately under address sanitizer. So if code is working just fine now it could still be buggy and not work on other platforms or when built by other compilers.
  - jstimpfle 9y ago
    Yep - might do. Unfortunately, to be honest, the OpenGL implementation I use printed quite a bit of a mess when run under valgrind, so I haven't tried again. (Could improve the architecture to bench separately). Update: tried and valgrind doesn't report problems in my own code under normal operation, except for me being sloppy at shutdown :-)
    - 2trill2spill 9y ago
      Check out the docs for suppressing errors in valgrind[1]. Also try the various compiler sanitizers, as well as the clang static analyzer and if your project is open source, coverity. [1]: http://valgrind.org/docs/manual/manual-core.html#manual-core.suppress http://valgrind.org/docs/manual/manual-core.html#manual-core...

jstimpfle 9y ago

I don't even use any tooling except occasionally a debugger (gdb on Linux / Visual studio on Windows). I have spent more than 500 hours of the last 8 months in C (no complicated data structures), and I'm pretty sure I've spent less than 2 hours total tracing memory bugs. (not saying there aren't more hidden).

2trill2spill 9y ago
Use as many tools as your platform supports. I've had "stable" C code run just fine for two years but come crashing to a halt immediately under address sanitizer. So if code is working just fine now it could still be buggy and not work on other platforms or when built by other compilers.
- jstimpfle 9y ago
  Yep - might do. Unfortunately, to be honest, the OpenGL implementation I use printed quite a bit of a mess when run under valgrind, so I haven't tried again. (Could improve the architecture to bench separately). Update: tried and valgrind doesn't report problems in my own code under normal operation, except for me being sloppy at shutdown :-)
  - 2trill2spill 9y ago
    Check out the docs for suppressing errors in valgrind[1]. Also try the various compiler sanitizers, as well as the clang static analyzer and if your project is open source, coverity. [1]: http://valgrind.org/docs/manual/manual-core.html#manual-core.suppress http://valgrind.org/docs/manual/manual-core.html#manual-core...