Changed behavior of string.Empty (or System.String::Empty) in .NET 4.5

Question

Short version:

The C# code

typeof(string).GetField(\"Empty\").SetValue(null, \"Hello world!\");
Console.WriteLine(string.Empty);


        

Answer 1

I don't have an answer, juste some hint, maybe.

The only difference I see between String::Empty and System.Diagnostics.Debugger::DefaultCategory is the first one is tagged with __DynamicallyInvokableAttribute.

I dont' known the meaning of this undocumented attribute. A question about this attribute has been asked on SO: What is the __DynamicallyInvokable attribute for?

I can only suppose that this attribute is catch by the runtime to do some caching ?

Answer 2

The difference lies in the JIT for the new release of .NET, which apparently optimizes references to String.Empty by inlining a reference to a particular String instance rather than load the value stored in the Empty field. This is justified under the definition of the init-only constraint in ECMA-335 Partition I §8.6.1.2, which can be interpreted to mean the value of the String.Empty field will not change after the String class is initialized.

Answer 3

Because it can.

The value of these system-defined initonly fields are global invariants for the .NET runtime. If these invariants are broken, there are no longer any guarantees whatsoever regarding the behavior.

In C++, we would probably have a rule designating this as causing undefined behavior. In .NET, it is also undefined behavior, simply by the absence of any rule saying what happens when System.String.Empty.Length > 0. The whole specification of all layers of .NET and C# describe the behavior when System.String.Empty.Length == 0 and a whole bunch of invariants also hold.

For more information about optimizations which vary between runtimes and the implications, see the answers to

• What are the implications of asking Reflection APIs to overwrite System.String.Empty?