Are C# uninitialized variables dangerous?

by

I am under the impression that there are not truly “unassigned” values allowed by the runtime. In particular that a reference type that is not initialized will always have a null value, never the value left over from a previous invocation of the method or random value. Is this correct?

I note that no one has actually answered your question yet.

The answer to the question you actually asked is “sorta”.

As others have noted, some variables (array elements, fields, and so on) are classified as being automatically “initially assigned” to their default value (which is null for reference types, zero for numeric types, false for bools, and the natural recursion for user-defined structs).

Some variables are not classified as initially assigned; local variables in particular are not initially assigned. They must be classified by the compiler as “definitely assigned” at all points where their values are used.

Your question then is actually “is a local variable that is classified as not definitely assigned actually initially assigned the same way that a field would be?” And the answer to that question is yes, in practice, the runtime initially assigns all locals.

This has several nice properties. First, you can observe them in the debugger to be in their default state before their first assignment. Second, there is no chance that the garbage collector will be tricked into dereferencing a bad pointer just because there was garbage left on the stack that is now being treated as a managed reference. And so on.

The runtime is permitted to leave the initial state of locals as whatever garbage happened to be there if it can do so safely. But as an implementation detail, it does not ever choose to do so. It zeros out the memory for a local variable aggressively.

The reason then for the rule that locals must be definitely assigned before they are used is not to prevent you from observing the garbage uninitialized state of the local. That is already unobservable because the CLR aggressively clears locals to their default values, the same as it does for fields and array elements. The reason this is illegal in C# is because using an unassigned local has high likelihood of being a bug. We simply make it illegal, and then the compiler prevents you from ever having such a bug.

More Related Contents:

  1. Casting vs using the ‘as’ keyword in the CLR
  2. Why is stack size in C# exactly 1 MB?
  3. Performance surprise with “as” and nullable types
  4. Stack capacity in C#
  5. Why cannot C# generics derive from one of the generic type parameters like they can in C++ templates? [duplicate]
  6. Resolve assembly references from another folder
  7. Module initializers in C#
  8. explicitly cast generic type parameters to any interface
  9. Initialization of instance fields vs. local variables
  10. What is a “rooted reference”?
  11. Try-catch speeding up my code?
  12. Hosting CLR in Delphi with/without JCL – example
  13. Should we always include a default constructor in the class?
  14. Why does C#/CLR not support method override co/contra-variance?
  15. .NET 4.0 and the dreaded OnUserPreferenceChanged Hang
  16. How to detect which .NET runtime is being used (MS vs. Mono)?
  17. Is casting the same thing as converting?
  18. In a switch vs dictionary for a value of Func, which is faster and why?
  19. Why does Random.Next() always return the same number [duplicate]
  20. How to debug System.TypeLoadException errors in .NET?
  21. How many String objects will be created when using a plus sign?
  22. Are static indexers not supported in C#? [duplicate]
  23. What is the maximum length of a C#/CLI identifier?
  24. Simplest way to make cross-appdomain call?
  25. How are String and Char types stored in memory in .NET?
  26. Can you have multiple enum values for the same integer? [duplicate]
  27. Retrieve JIT output
  28. Where is the .NET JIT-compiled code cached?
  29. Where is the .NET JIT-compiled code cached?
  30. Why value-types are stored onto Stacks?

Leave a Comment