Skip to main content
added 159 characters in body
Source Link
Toby Speight
  • 88.3k
  • 14
  • 104
  • 327

I think that abuf_append() really needs a [[nodiscard]] attribute. If the function doesn't manage to perform the requested action, the addend could easily be lost if the caller ignores the return value.


A factor 2 growth rate is probably a bit large - common realloc strategies tend towards capacity * 3 / 2 or thereabouts. I'd prefer to see next_capacity() as a (static) function rather than a macro.


We have a bug when realloc() fails - after we have increased capacity. Don't store the new capacity until we have successfully reallocated.


We can save on allocations if users are able to reset an existing buffer - perhaps call that abuf_clear()?.

We could be more robust against use-after-free by setting buf = nullptr and count = capacity = 0u in abuf_free(). Then the buffer is still in a valid state and can be used again.

I think that abuf_append() really needs a [[nodiscard]] attribute. If the function doesn't manage to perform the requested action, the addend could easily be lost if the caller ignores the return value.


A factor 2 growth rate is probably a bit large - common realloc strategies tend towards capacity * 3 / 2 or thereabouts. I'd prefer to see next_capacity() as a (static) function rather than a macro.


We have a bug when realloc() fails - after we have increased capacity. Don't store the new capacity until we have successfully reallocated.

I think that abuf_append() really needs a [[nodiscard]] attribute. If the function doesn't manage to perform the requested action, the addend could easily be lost if the caller ignores the return value.


A factor 2 growth rate is probably a bit large - common realloc strategies tend towards capacity * 3 / 2 or thereabouts. I'd prefer to see next_capacity() as a (static) function rather than a macro.


We have a bug when realloc() fails - after we have increased capacity. Don't store the new capacity until we have successfully reallocated.


We can save on allocations if users are able to reset an existing buffer - perhaps call that abuf_clear()?.

We could be more robust against use-after-free by setting buf = nullptr and count = capacity = 0u in abuf_free(). Then the buffer is still in a valid state and can be used again.

added 159 characters in body
Source Link
Toby Speight
  • 88.3k
  • 14
  • 104
  • 327

I think that abuf_append() really needs a [[nodiscard]] attribute. If the function doesn't manage to perform the requested action, the addend could easily be lost if the caller ignores the return value.


A factor 2 growth rate is probably a bit large - common realloc strategies tend towards capacity * 3 / 2 or thereabouts. I'd prefer to see next_capacity() as a (static) function rather than a macro.


We have a bug when realloc() fails - after we have increased capacity. Don't store the new capacity until we have successfully reallocated.

I think that abuf_append() really needs a [[nodiscard]] attribute. If the function doesn't manage to perform the requested action, the addend could easily be lost if the caller ignores the return value.


A factor 2 growth rate is probably a bit large - common realloc strategies tend towards capacity * 3 / 2 or thereabouts. I'd prefer to see next_capacity() as a (static) function rather than a macro.

I think that abuf_append() really needs a [[nodiscard]] attribute. If the function doesn't manage to perform the requested action, the addend could easily be lost if the caller ignores the return value.


A factor 2 growth rate is probably a bit large - common realloc strategies tend towards capacity * 3 / 2 or thereabouts. I'd prefer to see next_capacity() as a (static) function rather than a macro.


We have a bug when realloc() fails - after we have increased capacity. Don't store the new capacity until we have successfully reallocated.

edited body
Source Link
toolic
  • 15.7k
  • 5
  • 29
  • 217

I think thanthat abuf_append() really needs a [[nodiscard]] attribute. If the function doesn't manage to perform the requested action, the addend could easily be lost if the caller ignores the return value.


A factor 2 growth rate is probably a bit large - common realloc strategies tend towards capacity * 3 / 2 or thereabouts. I'd prefer to see next_capacity() as a (static) function rather than a macro.

I think than abuf_append() really needs a [[nodiscard]] attribute. If the function doesn't manage to perform the requested action, the addend could easily be lost if the caller ignores the return value.


A factor 2 growth rate is probably a bit large - common realloc strategies tend towards capacity * 3 / 2 or thereabouts. I'd prefer to see next_capacity() as a (static) function rather than a macro.

I think that abuf_append() really needs a [[nodiscard]] attribute. If the function doesn't manage to perform the requested action, the addend could easily be lost if the caller ignores the return value.


A factor 2 growth rate is probably a bit large - common realloc strategies tend towards capacity * 3 / 2 or thereabouts. I'd prefer to see next_capacity() as a (static) function rather than a macro.

Source Link
Toby Speight
  • 88.3k
  • 14
  • 104
  • 327
Loading