7 ms·

Let's take some safe language, e.g. c# 1. object should not exist and the second free is incorrect In C# I can have to variables pointing to the same object,

Let's take some safe language, e.g. c# 1. object should not exist and the second free is incorrect In C# I can have to variables pointing to the same object, I null only one of them. The second should be nulled too, but it's not. That's a logic error. So in C# I end up with some object that should not be there, but it is. Which is better - doube-free or undestroyed object - depends on use case.

pjmlp 10y ago
The big difference that you are overlooking is that double free leads to memory corruption, with undefined behavior of program execution. It can crash right away, in a few seconds, minutes, hours later, or never and just keep generating corrupt data. Having a reference that the GC doesn't collect doesn't lead to memory corruption, just more being used than it should be.
- mikulas_florek 10y ago
  > Having a reference that the GC doesn't collect Using such object is/can be as dangerous. In fact I find double-free safer because it usually crashes (and in my code I do checks so it almost certainly crashes), while in C# I can happily use such object without knowing it. But as I said, it depends on specific use case.
  - stymaar 10y ago
    > In fact I find double-free safer because it usually crashes (and in my code I do checks so it almost certainly crashes) You don't know what an undefined behavior is, do you ? You cannot be sure it crashes since the compiler is allowed to do anything with the assumption it doesn't happen. It's absolutely legit for the compiler to remove all the code you added to check a double-free didn't happen because it is assuming that's dead code. See this post[1] from the LLVM blog which explains why you can't expect anything when you're triggering an UB. [1]: http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html?m=1 http://blog.llvm.org/2011/05/what-every-c-programmer-should-...
    - mikulas_florek 10y ago
      I know very well what UB is and I bet there is not a single big program which does not have undefined behaviour. I even rely on UB sometimes, because with well defined set of compilers and systems, it's in reality well defined. I was talking in general about "unsafe" languages. I use c++ in my projects and use custom allocators everywhere, so there is no problem with UB there. The custom allocators also do the checking against double-free.
      - xorblurb 10y ago
        What do you mean by checking against double-free? Either you pay a high runtime cost, or use unconventional (and somehow impractical in C++) means (e.g. fancy pointers everywhere with a serial number in them), or you can't check reliably. Standard allocators just don't check reliably, and thus do not provide sufficient safety. Anyway, double-free was only an example. The point is that a language can, or not, provide safety by itself. Not just allow you to create you own enriched subset that is safer than the base language (because you often are interested in safety of 3rd party components not written in your dialect and local idioms of the language) In the case of C and C++, they are full of UB, and in the general case UB means you are dead. I find that extremely unfortunate, but this is the reality I have to deal with, so I don't pretend it does not exist...
        mikulas_florek 10y ago
        > What do you mean by checking against double-free? I pay small runtime cost for the check by having guard values around every allocation. At first I wanted to enable it only in debug builds, but I am too lazy to disable it in release builds, so it's there too. Anyway the overhead is small and I do not allocate often during runtime. > Anyway, double-free was only an example. The point is that a language can, or not, provide safety by itself. I can write safe code in modern C++ (and probably in C) and I can write unsafe code in e.g. Rust, only difference is which mode is default for the language. On the other hand I have to be prepared to pay the performance (or other) price for safe code. > In the case of C and C++, they are full of UB, and in the general case UB means you are dead. I doubt there is a big C or C++ program without UB, does that mean they are all dead? I do not think so. > I find that extremely unfortunate, but this is the reality I have to deal with, so I don't pretend it does not exist... I do not like UB in C++ too, but mostly because it does not make sense on platforms I use. On the other hand I can understand that the language can not make such platform-specific assumptions. I can pretend UB does not exist with some restrictions. UB in reality does not mean that the compiler randomly do whatever he wants, it do whatever he wants but consistently. But as I said it twice, it depends on use case. Am I writing for SpaceX or some medical instruments? Probably not a good idead to ignore UB. Am I making writing a new Unreal Engine? Probably not a good idea to worry much about UB, since I would never finish.

pjmlp 10y ago

The big difference that you are overlooking is that double free leads to memory corruption, with undefined behavior of program execution. It can crash right away, in a few seconds, minutes, hours later, or never and just keep generating corrupt data. Having a reference that the GC doesn't collect doesn't lead to memory corruption, just more being used than it should be.

mikulas_florek 10y ago
> Having a reference that the GC doesn't collect Using such object is/can be as dangerous. In fact I find double-free safer because it usually crashes (and in my code I do checks so it almost certainly crashes), while in C# I can happily use such object without knowing it. But as I said, it depends on specific use case.
- stymaar 10y ago
  > In fact I find double-free safer because it usually crashes (and in my code I do checks so it almost certainly crashes) You don't know what an undefined behavior is, do you ? You cannot be sure it crashes since the compiler is allowed to do anything with the assumption it doesn't happen. It's absolutely legit for the compiler to remove all the code you added to check a double-free didn't happen because it is assuming that's dead code. See this post[1] from the LLVM blog which explains why you can't expect anything when you're triggering an UB. [1]: http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html?m=1 http://blog.llvm.org/2011/05/what-every-c-programmer-should-...
  - mikulas_florek 10y ago
    I know very well what UB is and I bet there is not a single big program which does not have undefined behaviour. I even rely on UB sometimes, because with well defined set of compilers and systems, it's in reality well defined. I was talking in general about "unsafe" languages. I use c++ in my projects and use custom allocators everywhere, so there is no problem with UB there. The custom allocators also do the checking against double-free.
    - xorblurb 10y ago
      What do you mean by checking against double-free? Either you pay a high runtime cost, or use unconventional (and somehow impractical in C++) means (e.g. fancy pointers everywhere with a serial number in them), or you can't check reliably. Standard allocators just don't check reliably, and thus do not provide sufficient safety. Anyway, double-free was only an example. The point is that a language can, or not, provide safety by itself. Not just allow you to create you own enriched subset that is safer than the base language (because you often are interested in safety of 3rd party components not written in your dialect and local idioms of the language) In the case of C and C++, they are full of UB, and in the general case UB means you are dead. I find that extremely unfortunate, but this is the reality I have to deal with, so I don't pretend it does not exist...
      - mikulas_florek 10y ago
        > What do you mean by checking against double-free? I pay small runtime cost for the check by having guard values around every allocation. At first I wanted to enable it only in debug builds, but I am too lazy to disable it in release builds, so it's there too. Anyway the overhead is small and I do not allocate often during runtime. > Anyway, double-free was only an example. The point is that a language can, or not, provide safety by itself. I can write safe code in modern C++ (and probably in C) and I can write unsafe code in e.g. Rust, only difference is which mode is default for the language. On the other hand I have to be prepared to pay the performance (or other) price for safe code. > In the case of C and C++, they are full of UB, and in the general case UB means you are dead. I doubt there is a big C or C++ program without UB, does that mean they are all dead? I do not think so. > I find that extremely unfortunate, but this is the reality I have to deal with, so I don't pretend it does not exist... I do not like UB in C++ too, but mostly because it does not make sense on platforms I use. On the other hand I can understand that the language can not make such platform-specific assumptions. I can pretend UB does not exist with some restrictions. UB in reality does not mean that the compiler randomly do whatever he wants, it do whatever he wants but consistently. But as I said it twice, it depends on use case. Am I writing for SpaceX or some medical instruments? Probably not a good idead to ignore UB. Am I making writing a new Unreal Engine? Probably not a good idea to worry much about UB, since I would never finish.