Hacker News Reader

Comment by AshamedCaptain | Hacker News Reader

I know absolutely nothing about Zig (but I know C) and when I read "FixedBufferAllocator" I immediately guessed what the problem would be. I can see why it is claimed as a C replacement.

I am actually kind of surprised the author spent so much time figuring it out. The name of the allocator is not that well-defined, but at least to me it hints of it being simpler rather than full-featured allocator. I would also imagine he's using this in a very anti-patternic way. One would guess the point of this would be to destroy the entire allocator on every iteration, rather than trying to free everything 'nicely' which would be a lot of wasted work. This is a rather common pattern in a lot of "high-level" embedded development like this.

View on HN

> I am actually kind of surprised the author spent so much time figuring it out.

I wouldn't be. People learn different programming techniques at different times. I'd actually assume quite a lot of programmers don't know what a bump allocator is and eventually run into one in the wild. Kudos for the author for successfully debugging and discovering that.

> One would guess the point of this would be to destroy the entire allocator on every iteration

Not necessarily every iteration, but yes, these allocators are meant to be reset to 0 at a known time, when it's safe to do so.

After reading the description of the problem, I also had the thought, "Maybe FixedBufferAllocator is a bump allocator?". So before reading further, I checked the documentation to see if I was right. Turns out .. there is no documentation for FixedBufferAllocator?

Here's the documentation page: https://ziglang.org/documentation/master/std/#A;std:heap.Fix.... It just lists a couple methods, most of which have the description "No documentation provided". From those docs, it doesn't even look like there's a way to allocate memory using the FixedBufferAllocator. You might guess that it implements a bump allocator based on the fact that it only has an 'end_index' and a slice, but wow, I feel like an allocator is the kind of thing you really want to have documented well; especially a bump allocator, and especially especially a bump allocator whose name makes it sound like a general purpose allocator which happens to allocate within a fixed buffer.

I knew it was still early for Zig, but that's a bit disappointing.

> From those docs, it doesn't even look like there's a way to allocate memory using the FixedBufferAllocator.

There is but not directly through the FBA, you need to get a concrete Allocator struct out of that by calling the allocator() or threadsafeAllocator() functions.

Yeah, I guessed it was something external. I just said it to illustrate how surprisingly incomplete the docs are, I would expect the docs for an allocator to include enough information to figure out how to allocate something with the allocator.

> I knew it was still early for Zig, but that's a bit disappointing.

They're pretty explicit about not taking too much effort to document stuff in the stdlib, because any given thing in there may or may not make the final cut when the stdlib is stabilized (this is deliberate because they don't want to make people pissed or burned out for putting effort into documentation that winds up getting nuked). While FBA (or something like it) will likely make the cut, I'd say, maybe give them a break?

That's interesting, all it told me is that it's fixed-size. Without more information, and likely as the author did, I'd have assumed something like a bitmap allocator, which is hardly complicated but is a lot "safer" than a bump allocator in the face of deallocations (though it is sensitive to fragmentation).

I feel like this could also be fixed by a simple algorithm to keep track of the start index in FixBufAlloc.

Not really. If you allocate a bunch of objects then deallocate one in the middle of the sequence neither head or tail will help you. And once you’ve done that you’ve hit holes you can’t track anymore.

To fix this issue you need a completely different allocator design, e.g. a bitmap, which can keep track of individual locations within its buffer.

To fix it completely yes, but to fix it sufficiently for the author I think this would be okay

> anti-patternic

patternic is not a word.

Why? All words are coined at some point.

well for one, because the correct word "idiomatic" already exists:

https://wikipedia.org/wiki/Programming_idiom

there's a lot of sunlight between the class of things that are idiomatic and the class of things that are anti-patterns; and there are likely things that are idiomatic but still anti-patterns (yes, you can do this, and if you did this it would look like this, and it causes no regression in this particular case, but don't get in the habit of doing it this way because it can cause a hard-to-spot regression in the general case)

> anti-patterns

I agree with all that, but patternic is not a word.

To you. English has a variety of suffixes that allow for exactly this kind of constructive generation of new words. Thus 'patternic' is a word precisely because it has just been coined. Or do you only ever approve of "dictionary" words without pondering where they might come from?

it's an idiotic construction— the prefix may be originally greek, but has taken a specific connotation in english, while 'pattern' is from french, and the '-y' suffix is more common in english anyway, so the correct form for the idea would of course be anti-pattern–y

It is now.

Huh? It is a perfectly cromulent word.

Reply on news.ycombinator.com