3 ms·

> the post reads like a problem in the C code. Exactly. All GC does is push down the code that can cause problems like double-frees into the language implement

> the post reads like a problem in the C code. Exactly. All GC does is push down the code that can cause problems like double-frees into the language implementation. It doesn't magically make problems like double-free bugs impossible, like so many people say. > I was replying about GC alternatives for automatic memory management. Then why did you respond to and quote something that was talking about something entirely different?

pjmlp 12y ago
> Exactly. All GC does is push down the code that can cause problems like double-frees into the language implementation. It doesn't magically make problems like double-free bugs impossible, like so many people say. The difference being the compiler vendor vs all the developers using the language. > Then why did you respond to and quote something that was talking about something entirely different? Maybe my bad English could not decipher "where the compiler could determine when they can be thrown away, matters would be different. (So, in other words, the compiler inserts `malloc` (or whatever) calls, and ensures that every variable created is either `free`d exactly once after it becomes unreachable".
coldtea 12y ago
>Exactly. All GC does is push down the code that can cause problems like double-frees into the language implementation. It doesn't magically make problems like double-free bugs impossible, like so many people say. That's like saying moving the likelihood of an event from 1/100 to 1/10000000, and only under very specific pre-conditions that are easily detactable, doesn't make it impossible. That is, you are technically correct, which is the worst kind of correct. The difference between double-free bugs in stuff "pushed down in the language implementation" and double-free bugs in programmer's own code is so huge, it's a total game changer.

pjmlp 12y ago

> Exactly. All GC does is push down the code that can cause problems like double-frees into the language implementation. It doesn't magically make problems like double-free bugs impossible, like so many people say. The difference being the compiler vendor vs all the developers using the language. > Then why did you respond to and quote something that was talking about something entirely different? Maybe my bad English could not decipher "where the compiler could determine when they can be thrown away, matters would be different. (So, in other words, the compiler inserts `malloc` (or whatever) calls, and ensures that every variable created is either `free`d exactly once after it becomes unreachable".

coldtea 12y ago

>Exactly. All GC does is push down the code that can cause problems like double-frees into the language implementation. It doesn't magically make problems like double-free bugs impossible, like so many people say. That's like saying moving the likelihood of an event from 1/100 to 1/10000000, and only under very specific pre-conditions that are easily detactable, doesn't make it impossible. That is, you are technically correct, which is the worst kind of correct. The difference between double-free bugs in stuff "pushed down in the language implementation" and double-free bugs in programmer's own code is so huge, it's a total game changer.