buffet

> Come again? Of course it can. Oh come on.. I'm pretty sure Walter meant taking a view kind of slice. Obviously one can always copy part of a string, but that's not what slice implies I think. > It can't be done in place, mind you, but that's a pretty bad way to do any string slicing, regardless of implementation, in a manual memory management environment. It's not bad. It's the best, most efficient way. O(1)-ish. > Do most programmers expect their slices to result in undefined behavior if they release the larger string they were made from? I doubt it. That's what copy-on-write is for : release of the parent is blocked until no views are left on it. I made a C String lib using CoW. It works well: https://github.com/alcover/buffet

Working on it so you don't have to ! You'll enjoy comfy stuff like let s = "string.." s += "handled" The runtime Buffer type is already operational (https://github.com/alcover/buffet)

> then what's the point? There's no point. Moreover, passing the length separately is annoying and error-prone. You can have both your models in a single type. That's what my buffer lib achieves : SSO + slicing. https://github.com/alcover/buffet

Made this C lib for exactly the reasons you mention. I love C but got mad at the constant bounds errors and copying. https://github.com/alcover/buffet

Dynamic allocation, SSO, views, refcounting, etc.. are spread on various implementations. C++ separates string and string_view. And they're not fully compatible. (Ex. you can't concat cross-type !?). Rust has str, &str, String Box<str>, ... ? In the spirit of "a slice of a string is still a string", why not pack it all into a single type ? And offer security in the process. Here's the scheme : https://github.com/alcover/buffet/raw/main/assets/schema.png Here's the code : https://github.com/alcover/buffet NB: I'm talking string/byte buffer. Higher string tooling like Utf8 would go a layer above.

> if you bft_free OWN with outstanding REFs, nothing happens and the bft_free on last REF does nothing as well so it becomes just a leak. I seem to have solved this with a `wantfree` flag. https://github.com/alcover/buffet/commit/ade05630aafdf5c940e...

(following a discussion from https://github.com/alcover/buffet/commit/eab9648ff19483f57fd...) > if nobody's looking, we are go https://github.com/alcover/buffet/blob/dee3eb65f37ca07ea3d27... And otherwise, when is it freed? The refcount mechanism looks wrong to me: either the ownership of internal data is shared between instances (it seems it is not the case), either the owner is well defined and does not need a refcount. It appears that the refcount is used to avoid freeing the owner data if Buffet views are still alive. But using the views after freeing the referenced data is incorrect usage anyway, so it looks like defensive programming, trading a use-after-free for a leak.