4 ms·

C is fundamentally difficult when it comes to miss-allocation of memory. intp = malloc(int); looks almost exactly the same as int*p = malloc(int); bit will wor

• joosters 13y ago
  If your compiler doesn't warn you about that, try upgrading to an alternative. Anything more recent than the last twenty years should do.
  • betterunix 13y ago
    I see an awful lot of C and C++ projects that generate large numbers of warnings during a build. It would be pretty easy to miss one like that.
    • kibibu 13y ago
      Which is why gcc -Werror is a good idea
      • betterunix 13y ago
        So you are going to take the time to correct hundreds or sometimes thousands of warnings in some open source program you need to use at your job?
        • kevinnk 13y ago
          No one said that... -Werror is good when you are developing, not when you are compiling someone else's code.
        • qznc 13y ago
          Every good programmer I met enables as many warnings as possible and strives for zero warnings. This is just professional practice like keeping your code in a version control system.
      • joosters 13y ago
        gcc/clang warns about this particular problem without any extra command-line options. You need to go out of your way to stop it complaining.
• asveikau 13y ago
  When I hear people say this I think "there's someone without a lot of exposure". Yes the mistakes do happen. Aside from the fact that bugs will happen with your high level languages too, when you get on a good stride with C you will find the mistakes not as frequent, and you will become good at debugging and fixing them when they do happen. As mentioned on this thread they won't go to zero, and I'll admit they'll sometimes be a different set of problems than with other languages. But it's not totally unmanageable or unapproachable. PS: your comment wold hold more weight if you had written C in your example. It looks like HN's italic formatter got in your way in the first snippet, but p = malloc(int) will not compile.
  • tptacek 13y ago
    It's just not true that experienced C programmers don't generate integer overflows. They do so routinely. Practicdally every large C codebase has had problems with them. Sqlite has had exploitable integer overflows. Even qmail had an LP64 bug. The grain of truth that makes your comment sound plausible is that bad programmers generate more integer overflows. But that's not the problem with C --- it's not that there are too many integer overflows, it's the very high likelihood that any given codebase harbors any of them.
    • asveikau 13y ago
      Again, I don't think I ever said that people will stop making mistakes, just that the frequency of mistakes and ability to deal with them when discovered (or even ability to discover them) will change with experience. I feel like too many people dismiss the problem as scary and intractable and that's IMO not a good reason to never write any C.
      • tptacek 13y ago
        If you read what I wrote up there again, I think you'll see that it actually is an argument for avoiding C.
  • betterunix 13y ago
    "bugs will happen with your high level languages too" Sure, but the nature of the bugs is different. In C and C++, you have low-level bugs and high-level bugs to deal with; in a high-level language, you almost never have to deal with low-level bugs. Pointers are an inherently low-level construct, which are necessary in low-level code but completely inappropriate in high-level code. "it's not totally unmanageable or unapproachable" It is, however, a waste of time and mental effort, and it leads to less reliable software. The majority of C and C++ programs are high level programs that neither require nor benefit from the low-level features of those languages; unfortunately, writing a non-trivial C/C++ program without using low-level features (like pointers) is impossible.
• dbaupp 13y ago
  This is a case when the int* p = malloc(sizeof *p); syntax is extremely useful: there's no risk of making a typo for complicated types.