4 ms·

>>remembering to free(); not to free() twice; You can set the pointer to NULL, then freeing again won't hurt >>not to use after free() Set the pointer to NUL

>>remembering to free(); not to free() twice; You can set the pointer to NULL, then freeing again won't hurt >>not to use after free() Set the pointer to NULL so it will crash. >> Its main problem is that it has no non-wizardry high level semantics for parallelism. Fair, the language doesn't have it. For everyday programming though you can use something like OpenMP where making things execute in parallel often requires adding one line above your for loop. >>But there's no way I'd willingly start a new project in C today given the alternatives There is no alternative for performance critical code (well, at least among popular languages of today). For other things - sure. >>I'm going with one that gives me a reasonable shot at writing safe, fast, and understandable code. If safety is your priority then likely C is not for you. As to performance it depends what you consider fast. If making stuff 50% faster no matter how fast it already is saves a lot of money you have no choice but C/C++/Fortran or just hand code in assembly.

steveklabnik 10y ago
> Set the pointer to NULL so it will crash. Dereferencing NULL is not guaranteed to crash. It's undefined behavior, generally. SO that can lead to tons of other problems.... > There is no alternative for performance critical code On many platforms, Rust exists today. C is still the king of that, though, especially for obscure embedded stuff.
- bluecalm 10y ago
  Right. Still, in practice, if you are setting pointers to NULL after freeing them (to say "there is nothing there" if some other part of the program wants to check) you will get a crash (as the compiler won't be able to prove the pointer is NULL if setting it to NULL depends on what happens at runtime). I agree it's not perfect solution, just something to help you catching errors in your logic (not checking for NULL when something could be NULL is a bug in program logic).
  - steveklabnik 10y ago
    If the zero address is valid, then one aspect of "undefined behavior" is that the result is "this will actually continue to 'work' until something random goes wrong". Someone just the other day on Reddit was talking about how this is a common issue in their workplace, as they work on a system that maps valid memory to 0.
rrauenza 10y ago
>>> remembering to free(); not to free() twice; > You can set the pointer to NULL, then freeing again won't hurt >>> not to use after free() > Set the pointer to NULL so it will crash. I like C and think it is bashed too much, but double frees and invalid pointers are most often the result of multiple copies of the pointer... some other structure hanging onto the original reference.
- chelahmy 10y ago
  > some other structure hanging onto the original reference. Let's unleash the superpower of C. You should've been using pointers to a pointer so that it is always a single reference to a memory block. You can't really be programming in C if you're not thinking in pointers. One more thing; The article should have mentioned "pointer increment" which has nothing to do with "+= 1".
  - kbp 10y ago
    > One more thing; The article should have mentioned "pointer increment" which has nothing to do with "+= 1". What do you mean? ++ptr is perfectly equivalent to ptr += 1, for any pointer type.
    - deleted 10y ago
      [deleted]
    - chelahmy 10y ago
      I read it as integer arithmetic. It is semantically different from pointer arithmetic.
  - rrauenza 10y ago
    So it's turt^H^H^H^Hpointers all the way down?
    - chelahmy 10y ago
      Will the following help with the depth, or any depth? int *a, **b, **c, **d; d = c = b = &a;
module0000 10y ago
Just to add, that if you commonly make those mistakes in C/C++, it's time to learn to use lint. While humans commonly make these mistakes and fail to notice them, lint will scream quite loudly at you until they are fixed. If you are writing code that is too complex to be linted, then you are also are at a level of expertise where those mistakes are absent or very uncommon.
bbatha 10y ago
> Set the pointer to NULL so it will crash. This doesn't work on all architectures which is why its undefined behavior.
- EpicEng 10y ago
  Yet it will on the vast majority.
ArkyBeagle 10y ago
I really have to disagree - I've seen and written a lot of perfectly safe C code. There are a lot of good reasons not to use C but that one's a rapdily expanding fallacy. There is something missing from these discussions.
- nickpsecurity 10y ago
  "There is something missing from these discussions." The reasons for the gap between the condition of most C code and what you describe. Plus how to close that gap with lower effort than just getting them to use Ada, Component Pascal, Go, Rust, etc. I am keeping some notes on these discussions. Remembering you and TickleSteve in mind for the eventual roundtable discussion on Doing C Right With Ease (TM). pjmpl's list of safety tricks in the reply to you looks interesting, too. Once a basic strategy forms, then tooling can be designed to analyze conformance to it with helpful error messages and justifications. Built into IDE running in background as developer programs.
  - ArkyBeagle 10y ago
    Well, it's not that I haven't thought about how to write a paper on the subject. But frankly, the timbre of these discussions leads me to believe I'd simply be defending that for hours on end and I just don't wanna fool with it. The sheer rush to judgement is enough to make me think I'm sort of out of my depth in the ability to actually debate this properly. Part of my desire to say anything is trying to get the color and shape of that. Plus, I'd rather not break anonymity, and I (amusingly) don't own any code of consequence that could demonstrate the principles - it's all owned by my employers. Something like that - if I can't visualize the end-game, I probably have no business starting in it. Plus, I feel somewhat strongly that the languages designed to replace C should probably be given a chance. Throw in that the compiler people, in chasing absolutely performant executables, have left old code to rot... I'm also a bit feeling out of my depth. I can more do it than talk about it.

steveklabnik 10y ago

> Set the pointer to NULL so it will crash. Dereferencing NULL is not guaranteed to crash. It's undefined behavior, generally. SO that can lead to tons of other problems.... > There is no alternative for performance critical code On many platforms, Rust exists today. C is still the king of that, though, especially for obscure embedded stuff.

bluecalm 10y ago
Right. Still, in practice, if you are setting pointers to NULL after freeing them (to say "there is nothing there" if some other part of the program wants to check) you will get a crash (as the compiler won't be able to prove the pointer is NULL if setting it to NULL depends on what happens at runtime). I agree it's not perfect solution, just something to help you catching errors in your logic (not checking for NULL when something could be NULL is a bug in program logic).
- steveklabnik 10y ago
  If the zero address is valid, then one aspect of "undefined behavior" is that the result is "this will actually continue to 'work' until something random goes wrong". Someone just the other day on Reddit was talking about how this is a common issue in their workplace, as they work on a system that maps valid memory to 0.

rrauenza 10y ago

>>> remembering to free(); not to free() twice; > You can set the pointer to NULL, then freeing again won't hurt >>> not to use after free() > Set the pointer to NULL so it will crash. I like C and think it is bashed too much, but double frees and invalid pointers are most often the result of multiple copies of the pointer... some other structure hanging onto the original reference.

chelahmy 10y ago
> some other structure hanging onto the original reference. Let's unleash the superpower of C. You should've been using pointers to a pointer so that it is always a single reference to a memory block. You can't really be programming in C if you're not thinking in pointers. One more thing; The article should have mentioned "pointer increment" which has nothing to do with "+= 1".
- kbp 10y ago
  > One more thing; The article should have mentioned "pointer increment" which has nothing to do with "+= 1". What do you mean? ++ptr is perfectly equivalent to ptr += 1, for any pointer type.
  - deleted 10y ago
    [deleted]
  - chelahmy 10y ago
    I read it as integer arithmetic. It is semantically different from pointer arithmetic.
- rrauenza 10y ago
  So it's turt^H^H^H^Hpointers all the way down?
  - chelahmy 10y ago
    Will the following help with the depth, or any depth? int *a, **b, **c, **d; d = c = b = &a;

module0000 10y ago

Just to add, that if you commonly make those mistakes in C/C++, it's time to learn to use lint. While humans commonly make these mistakes and fail to notice them, lint will scream quite loudly at you until they are fixed. If you are writing code that is too complex to be linted, then you are also are at a level of expertise where those mistakes are absent or very uncommon.

bbatha 10y ago

> Set the pointer to NULL so it will crash. This doesn't work on all architectures which is why its undefined behavior.

EpicEng 10y ago
Yet it will on the vast majority.

ArkyBeagle 10y ago

I really have to disagree - I've seen and written a lot of perfectly safe C code. There are a lot of good reasons not to use C but that one's a rapdily expanding fallacy. There is something missing from these discussions.

nickpsecurity 10y ago
"There is something missing from these discussions." The reasons for the gap between the condition of most C code and what you describe. Plus how to close that gap with lower effort than just getting them to use Ada, Component Pascal, Go, Rust, etc. I am keeping some notes on these discussions. Remembering you and TickleSteve in mind for the eventual roundtable discussion on Doing C Right With Ease (TM). pjmpl's list of safety tricks in the reply to you looks interesting, too. Once a basic strategy forms, then tooling can be designed to analyze conformance to it with helpful error messages and justifications. Built into IDE running in background as developer programs.
- ArkyBeagle 10y ago
  Well, it's not that I haven't thought about how to write a paper on the subject. But frankly, the timbre of these discussions leads me to believe I'd simply be defending that for hours on end and I just don't wanna fool with it. The sheer rush to judgement is enough to make me think I'm sort of out of my depth in the ability to actually debate this properly. Part of my desire to say anything is trying to get the color and shape of that. Plus, I'd rather not break anonymity, and I (amusingly) don't own any code of consequence that could demonstrate the principles - it's all owned by my employers. Something like that - if I can't visualize the end-game, I probably have no business starting in it. Plus, I feel somewhat strongly that the languages designed to replace C should probably be given a chance. Throw in that the compiler people, in chasing absolutely performant executables, have left old code to rot... I'm also a bit feeling out of my depth. I can more do it than talk about it.