4 ms·

On some platforms, malloc(3) and free(3) are implemented in terms of mmap(2) and munmap(2). Which means, if you go beyond your buffer space, you'll end up i

On some platforms, malloc(3) and free(3) are implemented in terms of mmap(2) and munmap(2). Which means, if you go beyond your buffer space, you'll end up in an unmapped page and cause a SIGSEGV or end up in NULL data. Since they used the freelist/malloc wrappers, they avoided this trap. Plus, IMO, if you're implementing a freelist, you're implementing 80% of what a malloc is anyways. It's _mostly_ freelist handling, the only way to add memory to a process aside from mmap(2) is setbrk(2). There's no way to give memory back, so they only thing left for a malloc implementation to do is create a freelist to reissue memory previously freed. You can say you're still backed by malloc(3) if you want, but you're only getting the setbrk(2) handling and throwing away everything else it's trying to provide you.

PythonicAlpha 13y ago
If you read my statement correctly, I did not say, that some forms of malloc would not be helpful in finding or even preventing the bug. I only attacked the statement, that some kind of malloc could magically help finding a bug in testing -- a bug that only appears when provoked (and when you come up with the idea, provoking it, you don't need any malloc anymore to find it).
- anaphor 13y ago
  Nobody said that it would help find it in testing. You're attacking a strawman. Edit: although that is also false if you are using a quickcheck-like testing framework. Edit2: the article may have been claiming that, but Ted did not claim that, nor did Theo.
PythonicAlpha 13y ago
I don't understand what you want to tell me with all you said, after the "Plus". The point of self implemented allocators is not, that they are all better than malloc or that the implementor is more wise or that there is some magical additional stuff or even that some code is saved (the oposite is true) ... The point is only, that malloc implements the most general case (what it must, since it is the magical "I can do it all" tool (at least in memory management)). When you go away from the general case you can find several specific cases, that can be implemented specialized for this case -- and those specific cases could be implemented very much more efficient (concerning speed, not coding!). That is the whole point. Also there are some specific allocators that also implement some safeguides for common memory problems. But that seems to be more of the exception, when I take into account the feedback.
- akira2501 13y ago
  What I was trying to convey is that if you say "I'll just implement a better freelist" you're really just fooling yourself. What you are doing is re-implementing most of malloc on top of malloc, poorly. If would have been better if they had gone whole-hog with a malloc library and built it from the ground up for their specific purposes instead of half-assed "freelist speedhacks."

PythonicAlpha 13y ago

If you read my statement correctly, I did not say, that some forms of malloc would not be helpful in finding or even preventing the bug. I only attacked the statement, that some kind of malloc could magically help finding a bug in testing -- a bug that only appears when provoked (and when you come up with the idea, provoking it, you don't need any malloc anymore to find it).

anaphor 13y ago
Nobody said that it would help find it in testing. You're attacking a strawman. Edit: although that is also false if you are using a quickcheck-like testing framework. Edit2: the article may have been claiming that, but Ted did not claim that, nor did Theo.

PythonicAlpha 13y ago

I don't understand what you want to tell me with all you said, after the "Plus". The point of self implemented allocators is not, that they are all better than malloc or that the implementor is more wise or that there is some magical additional stuff or even that some code is saved (the oposite is true) ... The point is only, that malloc implements the most general case (what it must, since it is the magical "I can do it all" tool (at least in memory management)). When you go away from the general case you can find several specific cases, that can be implemented specialized for this case -- and those specific cases could be implemented very much more efficient (concerning speed, not coding!). That is the whole point. Also there are some specific allocators that also implement some safeguides for common memory problems. But that seems to be more of the exception, when I take into account the feedback.

akira2501 13y ago
What I was trying to convey is that if you say "I'll just implement a better freelist" you're really just fooling yourself. What you are doing is re-implementing most of malloc on top of malloc, poorly. If would have been better if they had gone whole-hog with a malloc library and built it from the ground up for their specific purposes instead of half-assed "freelist speedhacks."