4 ms·
If you're writing a library, you're not writing a program. If you write a C library, it is a good practice to leave the allocations to the library user, or at
by linkdd 3y ago
If you're writing a library, you're not writing a program.
If you write a C library, it is a good practice to leave the allocations to the library user, or at least provide a way to override the library's allocator. Allowing your user to write a free-less *program*.
- MrJohz 3y agoAny large program is composed of libraries. They may not explicitly be described as libraries, or imported from external sources, but there will be abstraction boundaries somewhere. Which means that if you're writing a program, you probably are also writing one or more libraries.
- kbenson 3y agoThe difference is that if you're writing a program you know the scope of use of all libraries, whether they be externally loaded or internal abstraction boundaries, and also know the scope of use of the program, and can make a call as to whether cleanup during opetation is required.
- bluGill 3y agoNot really. In theory you can, but in practice there are parts written by a different team and you don't know the scope of there parts. I also know someone who maintains some Clinton era encryption. that code is controlled who can know about it as obsecurity was all you were allowed. There are other pathalogical cases where you can't know everything about your program-
- linkdd 3y agoObviously, the "free-less programs" are not a "one size fits all" option. Like pretty much everything in IT and the dev world.
- tom_ 3y agoBut those parts, if they exist, are irrelevant to the current discussion, because they are not the parts you are writing.
- kbenson 3y agoI was specifically thinking of "creating" when I said writing, not maintaining or extending. And yes, while it can still be large enough to have multiple people working on it, then the "you" is actually a group, and of course you will coordinate on what you're doing and can very easily confirm you all understand the boundaries of how the components you are creating interact. Extending something you did not originally write may be quite different, of course.
- avgcorrection 3y agoYeah I don’t know how a C library without `_free()` calls would work across FFI (like making bindings).
- the-smug-one 3y agoWhy would FFI be an issue?
- avgcorrection 3y agoMaybe you allocate a string and pass it to Rust code. Then the Rust code needs a way to free it (through `drop`).
- dwattttt 3y ago1st approach) you don't 2nd approach for when you ignore the first) you use a type that doesn't "own" the pointer, and have the FFI side that allocated it free it 3rd approach for when you find out you can't do the 2nd) hope that the "owned" type is actually generic over the allocator used, and make an allocator that doesn't free (or even better, calls the correct free over the FFI boundary). `allocator-api` is the effort in this direction.
- steveklabnik 3y agoIt’s important to use the same allocator to free as you allocate with. You can’t assume that the same allocator is linked to both sides, so if you are allocating and then giving something to something else over FFI, you want to make sure you give them a way to call back into you to free. This is true irrespective of language.
- erik_seaberg 3y agoCode gets reused unless you take steps to prevent it. Once upon a time, someone submitting a change to the self-driving car project unknowingly broke Google’s web search engine. Someone else decided that was insane, and that’s why Bazel rules now let you limit who can depend on you in a monorepo.