3 ms·

(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.

(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.

musjleman 5y ago
> More like UAF ? Also, you can't. That was the idea. But it seems a bad one, according to you and user rom1v. 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. struct Buffet { union { struct { // | u32 refcnt | char data[] | void* ptr; // --------------^ points to data. at offset -4 is refcount / start of alloc SIZE_TYPE size; } large; // cap > sizeof(void*) + sizeof(SIZE_TYPE) char small[sizeof(void*) + sizeof(SIZE_TYPE)]; // cap <= sizeof(void*) + sizeof(SIZE_TYPE) } storage; SIZE_TYPE cap; // on big endian this value could also function as the null terminating byte }
- alcover 5y ago
  > 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/ade05630aafdf5c940ec6710bb7378ed80d5b96f#diff-335a4f89272fbd482c75dcfe16293e063731898c6e08668f47611557723b9912R230 https://github.com/alcover/buffet/commit/ade05630aafdf5c940e...

musjleman 5y ago

> More like UAF ? Also, you can't. That was the idea. But it seems a bad one, according to you and user rom1v. 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. struct Buffet { union { struct { // | u32 refcnt | char data[] | void* ptr; // --------------^ points to data. at offset -4 is refcount / start of alloc SIZE_TYPE size; } large; // cap > sizeof(void*) + sizeof(SIZE_TYPE) char small[sizeof(void*) + sizeof(SIZE_TYPE)]; // cap <= sizeof(void*) + sizeof(SIZE_TYPE) } storage; SIZE_TYPE cap; // on big endian this value could also function as the null terminating byte }

alcover 5y ago
> 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/ade05630aafdf5c940ec6710bb7378ed80d5b96f#diff-335a4f89272fbd482c75dcfe16293e063731898c6e08668f47611557723b9912R230 https://github.com/alcover/buffet/commit/ade05630aafdf5c940e...