Suppress emitting of
- Prototype: Not Started
- Implementation: Not Started
- Specification: Not Started
Allow suppressing emit of
localsinit flag via
Per CLR spec local variables that do not contain references are not initialized to a particular value by the VM/JIT. Reading from such variables without initialization is type-safe, but otherwise the behavior is undefined and implementation specific. Typically uninitialized locals contain whatever values were left in the memory that is now occupied by the stack frame. That could lead to nondeterministic behavior and hard to reproduce bugs.
There are two ways to "assign" a local variable:
- by storing a value or
- by specifying
localsinitflag which forces everything that is allocated form the local memory pool to be zero-initialized NOTE: this includes both local variables and
Use of uninitialized data is discouraged and is not allowed in verifiable code. While it might be possible to prove that by the means of flow analysis, it is permitted for the verification algorithm to be conservative and simply require that
localsinit is set.
Historically C# compiler emits
localsinit flag on all methods that declare locals.
While C# employs definite-assignment analysis which is more strict than what CLR spec would require (C# also needs to consider scoping of locals), it is not strictly guaranteed that the resulting code would be formally verifiable:
- CLR and C# rules may not agree on whether passing a local as
outargument is a
- CLR and C# rules may not agree on treatment of conditional branches when conditions are known (constant propagation).
- CLR could as well simply require
localinits, since that is permitted.
In high-performance application the cost of forced zero-initialization could be noticeable. It is particularly noticeable when
stackalloc is used.
In some cases JIT can elide initial zero-initialization of individual locals when such initialization is "killed" by subsequent assignments. Not all JITs do this and such optimization has limits. It does not help with
To illustrate that the problem is real - there is a known bug where a method not containing any
IL locals would not have
localsinit flag. The bug is already being exploited by users by putting
stackalloc into such methods - intentionally to avoid initialization costs. That is despite the fact that absence of
IL locals is an unstable metric and may vary depending on changes in codegen strategy.
The bug should be fixed and users should get a more documented and reliable way of suppressing the flag.
System.Runtime.CompilerServices.SkipLocalsInitAttribute as a way to tell the compiler to not emit
The end result of this will be that the locals may not be zero-initialized by the JIT, which is in most cases unobservable in C#.
In addition to that
stackalloc data will not be zero-initialized. That is definitely observable, but also is the most motivating scenario.
Permitted and recognized attribute targets are:
Constructor. However compiler will not require that attribute is defined with the listed targets nor it will care in which assembly the attribute is defined.
When attribute is specified on a container (
module, containing method for a nested method, ...), the flag affects all methods contained within the container.
Synthesized methods "inherit" the flag from the logical container/owner.
The flag affects only codegen strategy for actual method bodies. I.E. the flag has no effect on abstract methods and is not propagated to overriding/implementing methods.
This is explicitly a compiler feature and not a language feature.
Similarly to compiler command line switches the feature controls implementation details of a particular codegen strategy and does not need to be required by the C# spec.
Old/other compilers may not honor the attribute. Ignoring the attribute is compatible behavior. Only may result in a slight perf hit.
The code without
localinitsflag may trigger verification failures. Users that ask for this feature are generally unconcerned with verifiability.
Applying the attribute at higher levels than an individual method has nonlocal effect, which is observable when
stackallocis used. Yet, this is the most requested scenario.
localinitsflag when method is declared in
unsafecontext. That could cause silent and dangerous behavior change from deterministic to nonditerministic in a case of
localinitsflag always. Even worse than above.
stackallocis used in the method body. Does not address the most requested scenario and may turn code unverifiable with no option to revert that back.
- Should the attribute be actually emitted to metadata?