Repository navigation
Conversation
…libbzip2 libbzip2 requests every block through `BZALLOC(nnn)`, which calls `bzalloc(opaque, nnn, 1)`. libbz2-rs-sys calls `bzalloc(opaque, count, size_of::<T>())` instead, so an allocator written against the C library -- one that honours only the second argument, which the C library's calls have always allowed -- returned `count` bytes for a block of `count * size_of::<T>()` bytes. This patch passes the byte count (i.e., `items * size`) as `items` and size as 1. A count that does not fit the C int fails like a NULL return. Signed-off-by: Sergio Durigan Junior <sergiodj@chainguard.dev>
What do you mean by this? |
|
Thanks for the quick review. That's a fair point. My point here is that libbzip2 seems to have always called hooks as
If libbzip2-rs calls How would you feel about a patch to the documentation explaining that user-supplied hooks must honour both arguments? |
libbzip2 requests every block through
BZALLOC(nnn), which callsbzalloc(opaque, nnn, 1). libbz2-rs-sys callsbzalloc(opaque, count, size_of::<T>())instead, so an allocator written against the C library -- one that honours only the second argument, which the C library's calls have always allowed -- returnedcountbytes for a block ofcount * size_of::<T>()bytes.This patch passes the byte count (i.e.,
items * size) asitemsand size as 1. A count that does not fit the C int fails like a NULL return.Disclaimer: an LLM model was used to verify the patch's correctness. It also generated a reproducer for the issue which I'll be happy to post if necessary.