Re:Generic dynamic array in 60 lines of C
by marginalia_nu on Tuesday February 28, 2023 @03:41PM
(#34974537)
Is this overflow really a realistic scenario? I imagine most machines won't even permit you to allocate the sorts of sizes that would cause this bug.
Re:Generic dynamic array in 60 lines of C
by klyrs on Tuesday February 28, 2023 @04:12PM
(#34974926)
2Gb (1<<31 + 1 = boom) just isn't that much memory these days. If you're parsing large text files, for example, it's really easy to blow that limit. And what's the point of this dynamically-growing array if not to forget about managing capacity?
Re:Generic dynamic array in 60 lines of C
by nice_byte on Tuesday February 28, 2023 @03:21PM
(#34974291)
I have been using this for years. Capacity is not size. A zero size array will have non zero capacity. All c code is unsafe.
Re:Generic dynamic array in 60 lines of C
by klyrs on Tuesday February 28, 2023 @03:24PM
(#34974322)
Where do you check that capacity is nonzero? When capacity is zero, what happens on this line?
a.capacity <<= 1u;
I write a lot of c. Avoiding the unsafe bits, avoiding UB, is the skill required to write good c. "C code is unsafe" is a Rustacean marketing slogan. Don't believe it, but definitely don't practice it.
Re:Generic dynamic array in 60 lines of C
by nice_byte on Tuesday February 28, 2023 @03:36PM
(#34974467)
just don't initialize it with 0 capacity :-)
Re:Generic dynamic array in 60 lines of C
by skullt on Tuesday February 28, 2023 @04:06PM
(#34974844)
Why not just fix it? It's a trivial fix and has the added benefit that a zero-initialized DYN_ARR_OF(x) struct would be in a valid state, which is always nice. A struct with several dynamic arrays can then much simpler to initialize, for example.
For a library, if the user input is wrong, throw an error or an assertion failure. It shouldn't be causing an uninformative segmentation fault which your library does. The fix is a trivial. Why so defensive?
As fpoling points out, capacity is a 32-bit unsigned. That can overflow. There is no safety in append: if capacity is zero no new space will be made, if capacity overflows the realloc will not have enough space -- in either case, you end up writing past the end.
Allocating a [capacity] zero array and appending to it is extremely common. That you'll write past the end in that case shows that the author has barely even used this.
The code is unacceptably bad and unsafe. I don't usually do this, but I'm going to flag this post. I encourage everybody to do the same.
Apologies to the author. Golf is fun. This is uncool.
edit: changed size to [capacity]