| (author) Thank you a lot! I'm humbled by the attention you took. Please bear in mind I never intended to see this project publicized so early on the HN stage. I'm still experimenting in C, and it shows... That's a lot to chew on. For the moment : > Free'ing OWN before all refs = leak More like UAF ? Also, you can't. That was the idea. But it seems a bad one, according to you and user rom1v. > Reference count is non-atomic = potential corruption I'll try to make it so. This aspect is new to me. Anyway I hear it's quite hard, beyond that, to have a thread-safe lib, so I'll advertize it as non-TS. > branches Maybe that's the price for compacting str+str_view into a single type ? > enough footguns to worry about with 3 states. I agree the VUE should maybe drop. |
Well in your code 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'll try to make it so. This aspect is new to me. Anyway I hear it's quite hard, beyond that, to have a thread-safe lib, so I'll advertize it as non-TS.
IMO thread-safe should be the default with an easy opt-out by defining a single macro or something like that.
> Maybe that's the price for compacting str+str_view into a single type ?
Kind of. Without the VUE functionality I think you could refactor it into 2 states - SBO or REF.