# Decompiling C# 12 inline arrays and stackalloc: fixed buffers without the unsafe C# 12 added inline arrays, and they are easy to misread even in source: a fixed-size buffer that lives *inside* its containing struct, value-type all the way down, no heap allocation, no array object. It is the managed, safe answer to the C programmer's `int buf[8]` — the thing you previously could only get with an `unsafe` fixed-size buffer. Paired with `stackalloc`, which has been quietly modernised to hand you a `Span` instead of a raw pointer, you can now write buffer-heavy, allocation-free code without a single `unsafe` keyword. That safety is a source-level illusion built by the compiler, and the illusion is exactly what a decompiler has to reconstruct. Underneath, an inline array is not an array — it is a one-field struct with an attribute that tells the *runtime* to lay out N copies of the field. Element access is not `ldelem` — it is a call to a runtime intrinsic that returns a managed reference. And `stackalloc` is not safe at all underneath — it is a `localloc`, the rawest stack allocation the CLR has, wrapped in a `Span` constructor so the pointer never reaches your eyes. A decompiler that lowers to the metal and stops shows you ref arithmetic, helper calls with names you cannot type, and `unsafe` blocks that were never in the source. The code it emits often will not even recompile. This post walks the IL for both features and shows what a decompiler must recognise to put the source back together. ## An inline array is a struct wearing an attribute Here is the declaration and a trivial use: ```csharp [System.Runtime.CompilerServices.InlineArray(8)] public struct Buffer8 { private int _element0; } public static int Sum(Buffer8 buf) { int total = 0; for (int i = 0; i < 8; i++) total += buf[i]; return total; } ``` `Buffer8` has one field, `_element0`, and one attribute, `[InlineArray(8)]`. That is the whole trick: the attribute instructs the runtime to allocate the field eight times contiguously, so a `Buffer8` is 32 bytes and `buf[3]` means "the fourth `int` in that block." There is no array object and no length word — the length is baked into the attribute, known at compile time, and never stored at runtime. In metadata the type is a plain `sealed value type` with a single field. Nothing in the type definition says "array"; the only signal is the custom attribute: ``` .class public sequential ansi sealed beforefieldinit Buffer8 extends [System.Runtime]System.ValueType { .custom instance void [System.Runtime]System.Runtime.CompilerServices.InlineArrayAttribute::.ctor(int32) = ( 01 00 08 00 00 00 00 00 ) // InlineArray(8) .field private int32 _element0 } ``` A decompiler that classifies types by their shape sees a one-field struct and, unless it reads that attribute, prints it as a one-field struct — losing the entire meaning. So the first recognition rule is: **a value type carrying `[InlineArray(N)]` is an inline array of its single field's type, length N**, and it must be rendered with the attribute and the single backing field exactly as the compiler emitted them. ## Indexing lowers to a runtime intrinsic, not ldelem Now the access. `buf[i]` compiles not to an array-load but to a call that produces a managed reference to element `i`. The compiler routes it through a generated helper in `` that wraps `RuntimeHelpers.InlineArrayElementRef` (or builds a `Span` over the buffer with `InlineArrayAsSpan` and indexes that, depending on context). The read inside the loop lowers roughly to: ``` // total += buf[i]; ldarga.s buf ldloc i call !!1& [System.Runtime]System.Runtime.CompilerServices.RuntimeHelpers::InlineArrayElementRef(!!0&, int32) ldind.i4 add ``` The `InlineArrayElementRef` call takes a reference to the buffer and an index, and returns a *byref* to the element; `ldind.i4` then dereferences it to load the `int`. For a write you would see `stind.i4` against the same kind of ref. There is no `ldelem`, no bounds-check opcode pattern, nothing that looks like an array — just an intrinsic call returning a `ref`. A naive decompiler renders that literally: a call to `RuntimeHelpers.InlineArrayElementRef(ref buf, i)` followed by a dereference, or worse, a reference to a `` helper whose name contains characters you cannot write in C#. Either way the output does not say `buf[i]` and does not recompile. The recognition rule is: **a call to the inline-array element-ref intrinsic (or the generated helper around it) against an `[InlineArray]` type, followed by a load or store through the returned ref, is an indexer access — render it as `buf[i]`.** The same applies to the `InlineArrayAsSpan` form, which a decompiler should fold back either into element access or into a `Span` view of the buffer, depending on how the result is used.

## stackalloc is a localloc wearing a Span Now the second feature. Modern `stackalloc` assigned to a `Span` looks completely safe in source: ```csharp public static int SumFirstFour(ReadOnlySpan input) { Span scratch = stackalloc int[4]; for (int i = 0; i < 4; i++) scratch[i] = input[i] * input[i]; int total = 0; foreach (int v in scratch) total += v; return total; } ``` No `unsafe`, no pointer. But `stackalloc` has exactly one lowering: the `localloc` instruction, which allocates a block on the current method's stack frame and pushes a native pointer to it. The compiler sizes the block (`4 * sizeof(int)`), allocates, then constructs a `Span` over the raw pointer and the element count using the `Span(void*, int)` constructor: ``` // Span scratch = stackalloc int[4]; ldc.i4.4 conv.u ldc.i4.4 mul.ovf.un // 4 elements * 4 bytes localloc // -> native int (pointer to the stack block) ldc.i4.4 newobj instance void valuetype [System.Runtime]System.Span`1::.ctor(void*, int32) stloc.0 // scratch ``` That is the signature: an element-count `ldc`, a size multiply (`conv.u` / `mul.ovf.un`), a `localloc`, then a `newobj` on `Span::.ctor(void*, int32)`. A decompiler that renders those instructions literally produces an `unsafe` method with a `void*`, a multiplication, a `localloc` intrinsic (which C# cannot even express directly), and a `Span` constructor taking a pointer. None of that is in the source, and the `void*` forces an `unsafe` context the author deliberately avoided. The recognition rule folds the whole shape into one expression: **a `localloc` whose size is `count * sizeof(T)`, consumed by `Span` or `ReadOnlySpan`'s `(void*, int)` constructor, is `stackalloc T[count]`.** When the element type's size is a compile-time constant and the count is too, Glass reconstructs `stackalloc int[4]`; when the count is a variable, it reconstructs `stackalloc int[n]`. The raw pointer, the multiply, and the constructor all disappear back into the single `stackalloc` the author typed, and the method stays safe — no `unsafe` keyword, because the source had none. There is a subtlety worth naming: not every `stackalloc` becomes a `Span`. The older form, `int* p = stackalloc int[4];`, assigns the pointer directly and *is* genuinely unsafe — there the `void*` and `unsafe` belong in the output, because they were in the source. The decompiler distinguishes the two by what consumes the `localloc`: a `Span`/`ReadOnlySpan` constructor means the safe form, a direct pointer assignment means the unsafe form. Getting that distinction right is the difference between faithfully reproducing a safe method and falsely accusing it of being unsafe. ## Why faithful recovery matters here specifically For most language features, a decompiler that gets the details slightly wrong produces code that is ugly but still builds. These two are different, because both features exist precisely to give you low-level performance *while staying in safe, high-level C#* — and the incorrect decompilation destroys exactly that property. An inline array rendered as `InlineArrayElementRef` calls references helpers in ``, a compiler-internal type whose members have names containing `<` and `>` that are illegal in C# source. That output cannot be pasted back and compiled; it is a description of the IL, not a reconstruction of the program. A `stackalloc` rendered as `localloc` plus a `void*` turns a safe method into one that requires `unsafe`, misrepresenting the method's safety contract and, again, often failing to compile without edits the author never made. Glass reads both patterns at the level the author worked at. It classifies `[InlineArray(N)]` structs as inline arrays and renders their element access as indexers; it recognises the `localloc`-plus-`Span`-constructor shape as `stackalloc` and keeps the method safe, while still distinguishing the genuinely unsafe pointer form. The output reads like the source — `buf[i]` and `stackalloc int[4]` — and, just as importantly, recompiles like the source, which is the real test of whether a decompiler understood the program or merely transcribed its bytes. ## Summary Inline arrays and modern `stackalloc` are two of the clearest cases where the IL is dramatically lower-level than the C#. An inline array is a one-field struct whose `[InlineArray(N)]` attribute is the only evidence it is a buffer, indexed through runtime intrinsics that return byrefs rather than any array opcode. A `Span`-typed `stackalloc` is a raw `localloc` dressed in a `Span(void*, int)` constructor so the pointer never shows. A decompiler earns its keep by recovering the author's intent: the inline-array declaration and its indexers, the single `stackalloc` expression, and the safe, `unsafe`-free method body that made these features worth using in the first place.