# A Rare Bug in Audio Code by Zig’s Creator — Can You Find It? **URL:** \ **Category:** Challenge\ **Created:** [August 7, 2025, 10:56pm UTC](https://ziggit.dev/t/a-rare-bug-in-audio-code-by-zig-s-creator-can-you-find-it/11366 "2025-08-07T22:56:32Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![marler8997](https://ziggit.dev/user_avatar/ziggit.dev/marler8997/32/77_2.png) [@marler8997](https://ziggit.dev/u/marler8997)\ **Post date:** [August 7, 2025, 10:56pm UTC](https://ziggit.dev/t/a-rare-bug-in-audio-code-by-zig-s-creator-can-you-find-it/11366/1 "2025-08-07T22:56:32Z")
Considering how much of Andrew’s code I’ve seen, bugs are _abnormally rare_. Well… that makes today special…I actually found one! It’s in an example he wrote in his [pulseaudio](https://github.com/andrewrk/pulseaudio) fork (_very_ mission-critical code, of course). So here’s your chance to prove your intellect: can you spot the bug? > P.S. no cheating and looking at the PR queue where I explain it ```zig fn streamWriteCallback(stream: *pa.stream, requested_bytes: usize, userdata: ?*anyopaque) callconv(.c) void { const pulse: *Pulse = @ptrCast(@alignCast(userdata)); _ = pulse; std.log.info("requested bytes: {d}", .{requested_bytes}); var remaining_bytes = requested_bytes; while (remaining_bytes > 0) { var ptr_len: usize = remaining_bytes; var opt_ptr: ?[*]i32 = null; stream.begin_write(@ptrCast(&opt_ptr), &ptr_len) catch @panic("unhandleable error"); const ptr = opt_ptr orelse @panic("unhandleable error"); const write_len = @min(ptr_len, remaining_bytes); @memset(ptr[0..write_len], 0); stream.write(ptr, write_len, null, 0, .RELATIVE) catch @panic("unhandleable error"); remaining_bytes -= write_len; std.log.info("wrote {d} bytes, {d} remaining", .{ write_len, remaining_bytes }); } } ``` ---
**Author:** ![squeek502](https://ziggit.dev/user_avatar/ziggit.dev/squeek502/32/409_2.png) [@squeek502](https://ziggit.dev/u/squeek502)\ **Post date:** [August 7, 2025, 11:47pm UTC](https://ziggit.dev/t/a-rare-bug-in-audio-code-by-zig-s-creator-can-you-find-it/11366/2 "2025-08-07T23:47:27Z")
Hint: Working with the `W` suffixed Windows APIs will make you very aware of this class of bug ---
**Author:** ![floooh](https://ziggit.dev/user_avatar/ziggit.dev/floooh/32/2989_2.png) [@floooh](https://ziggit.dev/u/floooh)\ **Post date:** [August 8, 2025, 8:44am UTC](https://ziggit.dev/t/a-rare-bug-in-audio-code-by-zig-s-creator-can-you-find-it/11366/3 "2025-08-08T08:44:41Z")
Ah ok, `ptr[0..write_len]` with a i32 pointer when it should be a byte pointer - arguably also a failure of the Pulse Audio C API though (`void**`) PS: …I didn’t cheat, but after finding the problem I wanted to check if ChatGPT does too, and it did. Might be the one thing where LLMs can actually be useful 😉 ---
**Author:** ![matklad](https://ziggit.dev/user_avatar/ziggit.dev/matklad/32/2462_2.png) [@matklad](https://ziggit.dev/u/matklad)\ **Post date:** [August 8, 2025, 9:27am UTC](https://ziggit.dev/t/a-rare-bug-in-audio-code-by-zig-s-creator-can-you-find-it/11366/4 "2025-08-08T09:27:11Z")
I am a weak mind and just looked at the spoiler, but I want to mention that we follow pretty strict naming convention at TigerBeetle to minimize this sort of thing. We never use `len` / `length`. What we use are `count/index` and `size/offset`. - `size` is always size in bytes. `size == count * @sizeOf(T)` - `count` is always a 1-based logical number of items - `index` is always a 0-based index of logical item. `index` goes with `count` and `index + 1 == count` - `offset` is always a 0-based byte offset. `offset` goes with `size` and `offset + 1 == size` ---
**Author:** ![matklad](https://ziggit.dev/user_avatar/ziggit.dev/matklad/32/2462_2.png) [@matklad](https://ziggit.dev/u/matklad)\ **Post date:** [February 17, 2026, 4:33pm UTC](https://ziggit.dev/t/a-rare-bug-in-audio-code-by-zig-s-creator-can-you-find-it/11366/7 "2026-02-17T16:33:08Z")
@marler8997 I wrote an article to accompany your excellent illustration 😊 > **[Index, Count, Offset, Size](https://tigerbeetle.com/blog/2026-02-16-index-count-offset-size/)** > > Insights, updates, and technical deep dives on building a high-performance financial transactions database. ---
**Author:** ![usebeforefree](https://ziggit.dev/user_avatar/ziggit.dev/usebeforefree/32/6726_2.png) [@usebeforefree](https://ziggit.dev/u/usebeforefree)\ **Post date:** [August 8, 2025, 6:18pm UTC](https://ziggit.dev/t/a-rare-bug-in-audio-code-by-zig-s-creator-can-you-find-it/11366/5 "2025-08-08T18:18:41Z")
This instantly reminded me of: > Use explicitly sized types: Use data types with explicit sizes, like u32 or i64, instead of architecture-dependent types like usize. This keeps behavior consistent across platforms and avoids size-related errors, improving portability and reliability. from [Tiger Style](https://tigerstyle.dev/#1-core-principles) I recently came across of ---
**Author:** ![marler8997](https://ziggit.dev/user_avatar/ziggit.dev/marler8997/32/77_2.png) [@marler8997](https://ziggit.dev/u/marler8997)\ **Post date:** [August 10, 2025, 3:56pm UTC](https://ziggit.dev/t/a-rare-bug-in-audio-code-by-zig-s-creator-can-you-find-it/11366/6 "2025-08-10T15:56:12Z")
Thanks @matklad, I’ll be adopting this TigerBeetle convention: ![image](https://ziggit.dev/uploads/default/original/2X/7/7735d531dd9fb16340b29eb398f2e4fbac34ee51.png) ---
**Author:** ![glitchcake](https://ziggit.dev/user_avatar/ziggit.dev/glitchcake/32/2361_2.png) [@glitchcake](https://ziggit.dev/u/glitchcake)\ **Post date:** [April 19, 2026, 12:38pm UTC](https://ziggit.dev/t/a-rare-bug-in-audio-code-by-zig-s-creator-can-you-find-it/11366/8 "2026-04-19T12:38:48Z")
I’m a noob, what’s the meaning/significance of “with a i32 pointer when it should be a byte pointer”?