I’m writing processing of Air.Inst data for a project, and running into a confusing scenario when encountering .block instructions. The docs say they should have .ty_pl Data associated with them, but I am consistently getting a panic when trying to access that, and other, enum variants. In fact, it seems like the associated data is [_]u8{170} ** 12.
I’m trying to look through other other back-ends for codgen to see how/if they handle and acknowledge it, but they don’t seem to? c.zig just accesses the ty_pl field fearlessly.
Thank you for any tips/insider knowledge!
Welcome to Ziggit!
170 is 0xAA in hex, which is what Zig uses to fill undefined memory with in debug builds. block does have a ty_pl data field associated with it in well-formed AIR, so I suppose that you’re accessing invalid memory (maybe your indices are invalid or the Air instance you’re trying to access has already been deinitialized at that point?)
Also note that Air.unwrapBlock recently got merged which fetches the extra data for you.
1 Like
Thank you! That is enlightening. I’m not sure of the root cause (maybe raw iterating through air.instructions is inherently unsafe/potentially invalid), but I was able to find a solution in using air.getMainBody() (which has no docstring 
) by looking at the code for pretty-printing the AIR --verbose-air!