logoalt Hacker News

skavi • today at 2:24 PM • 1 reply • view on HN

I am going to ask a question that is is definitely not the place for, but I am not involved with Zig in any way and am curious, so I hope you'll indulge me.

I noticed the following comment was added to lib/std/multi_array_list.zig [0] with this change:

        /// This pointer is always aligned to the boundary `sizes.big_align`; this is not specified
        /// in the type to avoid `MultiArrayList(T)` depending on the alignment of `T` because this
        /// can lead to dependency loops. See `allocatedBytes` which `@alignCast`s this pointer to
        /// the correct type.
How could relying on `@alignOf(T)` in the definition of `MultiArrayList(T)` cause a loop? Even with `T` itself being a MultiArrayList, surely that is a fully distinct, monomorphized type? I expect I am missing something obvious.

[0]: https://codeberg.org/ziglang/zig/pulls/31403/files#diff-a6fc...

Replies

messe • today at 5:40 PM

I had to search for this, but managed to find the relevant mlugg@ comment[0] on the ZSF zulip:

> i had to change the bytes field from [*]align(@alignOf(T)) u8 to just [*]u8 (and cast the alignment back in the like one place that field is accessed). this wasn't necessary for MultiArrayList in and of itself, but it was necessary for embedding a MultiArrayList(T) inside of T without a dependency loop, like

    const T = struct {
        children: MultiArrayList(T),
    };
    // reproduced for completeness:
    fn MultiArrayList(comptime T: type) type {
        return struct {
            bytes: [*]align(@alignOf(T)) u8,
            // ...
        };
    }
[0]: https://zsf.zulipchat.com/#narrow/channel/454360-compiler/to...
➕ show 1 reply