(following a discussion from https://github.com/alcover/buffet/commit/eab9648ff19483f57fd41d92615a3e73163fcf5a#r68200348 https://github.com/alcover/buffet/commi

(following a discussion from https://github.com/alcover/buffet/commit/eab9648ff19483f57fd41d92615a3e73163fcf5a#r68200348 https://github.com/alcover/buffet/commit/eab9648ff19483f57fd...) > if nobody's looking, we are go https://github.com/alcover/buffet/blob/dee3eb65f37ca07ea3d27252eb07e6953457d52f/src/buffet.c#L217-L218 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.