3 ms·

The point is that they’re simple and direct. Replacing them with a big data structure and modern syntax is not as good as what people have done for decades: all

The point is that they’re simple and direct. Replacing them with a big data structure and modern syntax is not as good as what people have done for decades: allocate a pool of blocks to your exact liking.

commandlinefan 2y ago
I went into the article expecting the standard criticism of any and all things C: stupid people can do stupid things with them, so nobody should be allowed to use them. He instead pointed out some legitimate gotchas with malloc and free and offered a reasonable solution. I can't say that I see any problems with his proposed solution - his proposed API looks as simple and direct as old-style malloc and free to me.
- worthless-trash 2y ago
  Malloc never fails on linux in most configurations, problem #1. Overcommit and other "defaults" make this a non starter. If the API can't be trusted as accurate, the rest of the issues are not worth using. No matter how the 'api' is presented, it will still have the same problem.
  - rurban 2y ago
    Not everyone is using linux. malloc can fail, and should fail.
    - worthless-trash 2y ago
      > Not everyone is using linux. Correct, it also fails on IOS the same way ( https://www.mikeash.com/pyblog/friday-qa-2010-12-17-custom-object-allocators-in-objective-c.html#comment-6f3b9bf689eaf4ddec5473dd6dc1dce4 https://www.mikeash.com/pyblog/friday-qa-2010-12-17-custom-o... ), I haven't checked on more recent IOS versions, but it used to. I imagine that sooner than later apple may merge IOS and OSX kernels, who knows. If the solution proposed is not to work on the 3 of the common operating systems(IOS, ANDROID, LINUX) adoption may be a problem. > malloc can fail, Yes, only if you allocate greater than the virtual address space in a process, or if you don't use an optimistic allocator (or disable overcommit) it could, I suggest you try this to find some REAL shady offenders that just abuse memory use, lodge bugs and then record the response (or lack thereof). I have tried this for a bunch of utilities, and have had a hard time convincing software developers that they don't need to do insane things. > and should fail. I absolutely agree, fixing this problem means 'fixing and solving the problem for all software' which is something that is a very hard problem to solve, if you do find a way let me know.

commandlinefan 2y ago

I went into the article expecting the standard criticism of any and all things C: stupid people can do stupid things with them, so nobody should be allowed to use them. He instead pointed out some legitimate gotchas with malloc and free and offered a reasonable solution. I can't say that I see any problems with his proposed solution - his proposed API looks as simple and direct as old-style malloc and free to me.

worthless-trash 2y ago
Malloc never fails on linux in most configurations, problem #1. Overcommit and other "defaults" make this a non starter. If the API can't be trusted as accurate, the rest of the issues are not worth using. No matter how the 'api' is presented, it will still have the same problem.
- rurban 2y ago
  Not everyone is using linux. malloc can fail, and should fail.
  - worthless-trash 2y ago
    > Not everyone is using linux. Correct, it also fails on IOS the same way ( https://www.mikeash.com/pyblog/friday-qa-2010-12-17-custom-object-allocators-in-objective-c.html#comment-6f3b9bf689eaf4ddec5473dd6dc1dce4 https://www.mikeash.com/pyblog/friday-qa-2010-12-17-custom-o... ), I haven't checked on more recent IOS versions, but it used to. I imagine that sooner than later apple may merge IOS and OSX kernels, who knows. If the solution proposed is not to work on the 3 of the common operating systems(IOS, ANDROID, LINUX) adoption may be a problem. > malloc can fail, Yes, only if you allocate greater than the virtual address space in a process, or if you don't use an optimistic allocator (or disable overcommit) it could, I suggest you try this to find some REAL shady offenders that just abuse memory use, lodge bugs and then record the response (or lack thereof). I have tried this for a bunch of utilities, and have had a hard time convincing software developers that they don't need to do insane things. > and should fail. I absolutely agree, fixing this problem means 'fixing and solving the problem for all software' which is something that is a very hard problem to solve, if you do find a way let me know.