See the conversation here.
This code in SLE:
|
public override int Run(InterpretedFrame frame) |
|
{ |
|
if (frame.Peek() == null) |
|
{ |
|
frame.Pop(); |
|
frame.Push(Activator.CreateInstance(_defaultValueType)); |
has the possibility of behaving incorrectly if/when dotnet/csharplang#99 is implemented in the future. If the value type has a parameterless constructor present in IL, Activator.CreateInstance would run that parameterless constructor. Which means the value you get back from Nullable<T>.GetValueOrDefault() could be different if run through this code than if you actually called Nullable<T>.GetValueOrDefault() on a "null" value.
We should instead change this to use GetUninitializedObject which wouldn't run the parameterless constructor. (And of course add a test for this.)
See the conversation here.
This code in SLE:
runtime/src/libraries/System.Linq.Expressions/src/System/Linq/Expressions/Interpreter/TypeOperations.cs
Lines 155 to 160 in 8a52f1e
has the possibility of behaving incorrectly if/when dotnet/csharplang#99 is implemented in the future. If the value type has a parameterless constructor present in IL,
Activator.CreateInstancewould run that parameterless constructor. Which means the value you get back fromNullable<T>.GetValueOrDefault()could be different if run through this code than if you actually calledNullable<T>.GetValueOrDefault()on a "null" value.We should instead change this to use
GetUninitializedObjectwhich wouldn't run the parameterless constructor. (And of course add a test for this.)