Hacker News new | ask | show | jobs
by alcover 1566 days ago
(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.

1 comments

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