Reserve First

matklad · August 16, 2025, 7:31pm

Calder-Ty · August 17, 2025, 12:57am

Interesting. I’ll admit the Ghostty example made me question my understanding of defer and errdefer interaction

vulpesx · August 17, 2025, 12:58am

I like the idea of removing the growing append

andrewrk · August 17, 2025, 8:34am

Zig applications should consider aborting on OOM.

Perhaps - but reusable packages should not. And isn’t it nice to generally program with the same style, and be able to extract code from your application into a reusable package?

pineapplemachine · August 17, 2025, 8:48am

I like the idea of renaming appendAssumeCapacity to append and encouraging its use as default, but instead of removing growing append rename it to e.g. appendGrow. There are many cases where this distinction is not important, and expanding the amount of code needed to do basic operations on a data structure would only be encumbering.

asibahi · August 17, 2025, 9:13am

I have a question . How would you handle a function that collects items in an ArrayList , but returns an owned slice? toOwnedSlice does return an error but the only place for it that makes sense is the last statement in the function.

unless it is something like this, which feels like a bad idea.

return ret.toOwnedSlice(allocator) catch ret.items;

vulpesx · August 17, 2025, 9:34am

If you can calculate the exact capacity needed, then ret.items should be the whole allocation.

Otherwise, the best solution would be to return the array list and let the caller deal with it :3.

If you can’t/don’t want to do that, then you have to handle possible failure.

asibahi · August 17, 2025, 9:57am

I don’t usuallyy know the exact capacity, and I specifically don’t want to return an ArrayList. I want to return a nicely packaged slice, which makes for nicer API (and clearer data flow).

vulpesx · August 17, 2025, 10:05am

you could manually remap/resize the allocation which should reduce the possibility of failure, and reduce the half the maximum needed/assumed memory if you are doing that.

matklad · August 17, 2025, 10:40am

Yeah, my secret plan is to make people angry at the suggestion, and incentivize finding better ways to avoid these kinds of problems. Notably, std.testing.checkAllAllocationFailures doesn’t help here, as you need to continue using the data structure after allocation failure to hit the issues.

What would help is throwing in allocation errors to the mix in Swarm Testing Data Structures.

floooh · August 17, 2025, 10:41am

I feel like the next step in this chain of thought is to not dynamically grow-allocate at all but use a fully pre-allocated array with a max capacity, it could be called a ‘BoundedArray’

joed · August 17, 2025, 1:27pm

I think the end goal should be to eventually remove all memory allocation from the language. Even the stack.

Eliminating recursion? Let’s take it a step further and eliminate function calls altogether (all structured programming is now some abuse of a labelled switch). Returning a pointer to a stack variable? No longer a problem.

Good luck to Rust in competing with that level of memory safety.

floooh · August 17, 2025, 1:43pm

I realize you’re joking but tbh you can get surprisingly far without any dynamic memory allocation at all, e.g. in this Pacman clone all game state is in a single upfront defined global:

github.com/floooh/pacman.zig

src/pacman.zig

803dd2ddb


      
          // all mutable state is in a single nested global
          const State = struct {
              game_mode: GameMode = .Intro,
          
              timing: struct {
                  tick: u32 = 0,
                  laptime_store: u64 = 0,
                  tick_accum: i32 = 0,
              } = .{},
          
              input: struct {
                  enabled: bool = false,
                  up: bool = false,
                  down: bool = false,
                  left: bool = false,
                  right: bool = false,
                  esc: bool = false,
                  anykey: bool = false,
              } = .{},

This file has been truncated. show original

…the same in the C version:

github.com/floooh/pacman.c

pacman.c

04ec7c446


      
          // all state is in a single nested struct
          static struct {
          
              gamestate_t gamestate;  // the current gamestate (intro => game => intro)
          
              struct {
                  uint32_t tick;          // the central game tick, this drives the whole game
                  uint64_t laptime_store; // helper variable to measure frame duration
                  int32_t tick_accum;     // helper variable to decouple ticks from frame rate
              } timing;
          
              // intro state
              struct {
                  trigger_t started;      // tick when intro-state was started
              } intro;
          
              // game state
              struct {
                  uint32_t xorshift;          // current xorshift random-number-generator state
                  uint32_t hiscore;           // hiscore / 10

This file has been truncated. show original

…and my Zig emulator project is the same. The entire emulator state is in a single struct which doesn’t have any references to data outside that single nested struct (doesn’t look quite as impressive because the struct is declared elsewhere):

github.com/floooh/chipz

emus/bombjack/bombjack.zig

736f1fdaf


      
          const sokol = @import("sokol");
          const sapp = sokol.app;
          const slog = sokol.log;
          const host = @import("chipz").host;
          const Bombjack = @import("chipz").systems.bombjack.Bombjack;
          
          var sys: Bombjack = undefined;
          
          export fn init() void {
              host.audio.init(.{});
              host.time.init();
              host.prof.init();
              sys.initInPlace(.{
                  .audio = .{
                      .sample_rate = @intCast(host.audio.sampleRate()),
                      .callback = host.audio.push,
                  },

In the C version of those emulators I use this for snapshotting. I simply dump the entire emulator state struct via what’s essentially a memcpy into a file or the web browsers IndexedDB. This works because there are no references to outside data in the struct (there’s a handful of pointers inside the struct pointing to other parts of the struct, but those can be easily patched on save/load by replacing the pointers with offsets to the start of the struct before saving, and restoring the offsets to pointers after loading).

…the only dynamic allocations happen in the sokol headers (used for rendering, audio, input etc…), but only once at startup, and only a small number of allocations (you can configure a couple of pool sizes in the init calls which are then pre-allocated). And then of course there’s more dynamic allocations happening down in the operating system which I unfortunately don’t have any control over…

E.g. in ‘Zig terms’ it might be a totally valid strategy to pass slices to pre-allocated memory into libraries instead of allocators, or even go a step further and make the ‘max capacities’ build-time parameters which are baked into a custom-built executable on the user’s machine (which is much more feasible with Zig’s build.zig and build.zig.zon and easy to setup Zig toolchain compared to the C/C++ world).

iceghost · August 18, 2025, 7:34am

On a similar note, i used to read an article that talks about a lesson: limit the output for human consumption (i.e, human is bad at too much information), and limit the input for system resources. Use both of those to derive some reasonable upper bounds for buffers and allocations, so that your software doesnt redundantly use infinite amount of memory and run predictably.

The author is uhh… check notes, matklad

matklad · August 18, 2025, 9:03am

You said it much better than I did, will steal this phrase, thanks!

cztomsik · August 18, 2025, 11:49am

I’ve recently started doing something similar too (when I parse, I do two pases over the tokens, and during the first I perform some validations and compute how much memory I will need). It’s probably less efficient that way but I never worry too much about that.

I’ve also did a small helper container for this purpose. It’s only using debug.assert() and it never fails. I find it easier to use for such cases.

Also interesting - it can be used in comptime. It’s not effortless, you still need to init differently based on @inComptime() but the rest can be kept the same, including the .finish() which will also copy the slice for you if you are in comptime.

github.com/cztomsik/tokamak

src/util/buf.zig

main

const std = @import("std");

// This is useful mostly for parsing - it's a simple, slice-backed container
// that is not supposed to grow beyong its max size. It does not do any bounds
// checking, except maybe the peek/pop() which returns optional.
//
// The general pattern is that you do two passes over the input, first time you
// count the max len, without any need for allocation and then, in the second
// pass you use a previously created Buf(T) to build the result.
//
// A nice touch is that it can be used in comptime, and it provides finish()
// which also checks if the final size is the same.
pub fn Buf(comptime T: type) type {
    return struct {
        buf: []T = &.{},
        len: usize = 0,

        /// Init with an already existing slice
        pub fn init(buf: []T) @This() {
            return .{ .buf = buf };

This file has been truncated. show original

BTW: I’ve just noticed the BoundedArray was removed… I initially wanted to to use it but the main limitation was that it was not operating on externally provided buffer. I could also the ArrayListUnmanaged but I wanted to have .len as top-level field.

BTW2: In the regex.zig I’m also using two Buf(Ops)s pointing into a single slice of memory, and the count is therefore a sum of both upper-bounds.

tsdtas · August 19, 2025, 8:25am

Isn’t “validate, allocate, transform” a fairly standard pattern in C?

I’ve written a lot of code that looks something like this (error checking omitted for brevity)

int size = parse(NULL); // returns negative numbers for errors
char data = malloc(size);
parse(&data); // can't fail given correct size data and earlier call succeeded

cztomsik · August 19, 2025, 8:51am

I never did any C before so it totally might be, and I think you are right, I think I saw it in some C codebase(s) before (pango? and I think llama.cpp does that too) but back then I was rather puzzled why were they doing the work twice

My background is Delphi → PHP → Java → JS → Rust → Zig so Zig is really the first (serious) low-level encounter.

EDIT: I didn’t mean that I use the exact same function twice, just that I do some of the work again, so that I can save some work and checking later.

floooh · August 19, 2025, 9:13am

This style of first querying some required size by calling a function with some special null-pointer-arg and then calling that same function with a valid pointer again is used a lot in Win32, but as a C programmer I can’t say that I’m a fan of such ‘double-use’ functions…

It’s better to have a separate 'get_required_size()` function.

tsdtas · August 19, 2025, 11:34am

It’s better to have a separate 'get_required_size()` function.

Not saying it’s good, but especially for larger C APIs I think the double-call can be the least worst option in some scenarios.

Think of something like Vulkan. Your library is big and complicated, and your main consumer of the library isn’t people coding in C, but people writing bindings for other higher-level languages.

Would you really gain anything by replacing

result = vkEnumerateInstanceExtensionProperties( "name", &count, NULL )
// check result, allocate some memory
result = vkEnumerateInstanceExtensionProperties( "name", &count, &ptr )
// check result

with

result = vkGetInstanceExtensionPropertyCount( "name", &count )
// check result, allocate some memory
result = vkEnumerateInstanceExtensionProperties( "name", count, &ptr )
// check result

across a dozen or so functions?