Describe the validity of null managed pointers #71794
Conversation
- Declare that it is valid to have a null managed pointer, but declare it invalid to actually read from such a pointer - In practice this has always been legal, as it has been legal to managed pointer locals for years, and they are included in the list of values that are zeroinitialized on method start - Also clarify the rules to permit a managed pointer to the location directly following a managed object. - This is a new capability in the spec that will likely be useful for accessing fixed size data buffers held in objects of the GC heap. However, the GC has been able to tolerate this behavior for many years, so there is no code change necessary. Fixes dotnet#69690
davidwrighton
requested review from
GrabYourPitchforks,
AlekseyTs and
AaronRobinsonMSFT
ghost
assigned 
| @@ -987,6 +987,10 @@ https://www.ecma-international.org/publications-and-standards/standards/ecma-335 | |||
| ### I.8.9.2 | |||
| - Insert at the end of the first paragraph “An unmanaged pointer type cannot point to a managed pointer.” | |||
|
|
|||
| ### II.14.4.2 | |||
| - Replace the sentence "Managed pointers (&) can oint to an instance of a value type, a field of an object, a field of a value type, an element of an array, or the address where an element just past the end of an array would be stored (for pointer indexes into managed arrays)." with "Managed pointers (&) can point to a local variable, a method argument, a field of an object, a field of a value type, an element of an array, a static field, the address just past the end of an object, or the address where an element just past the end of an array would be stored (for pointer indexes into managed arrays)." | |||
| - Replace the sentence "Managed pointers cannot be null, and they shall be reported to the garbage collector even if they do not point to managed memory." with "Managed pointers shall be reported to the garbage collector even if they do not point to managed memory. A null managed pointer must not be dereferenced." | |||
There was a problem hiding this comment.
What is the significance of "Managed pointers shall be reported to the garbage collector even if they do not point to managed memory."? It feels like a internal implementation detail that does not need to be in the spec.
There was a problem hiding this comment.
Agreed. I think we should strike the entire sentence. It is in section II.14.4.2 Managed pointers. The meta point seems to be around stating the non-nullable nature of a managed pointer and that invalid pointers can cause problems. I don't think this matters in the spec as it sounds like it is attempting to say that "pointers to non-managed memory are bad", which for the spec is fair and results in undefined behavior, but implementations are free to be resilient to that.
There was a problem hiding this comment.
I would be explicit in the previous sentence and simply state managed pointers may be null.
There was a problem hiding this comment.
The particular detail I think its trying to specify, (and it's doing it poorly) is that a managed pointer cannot be an arbitrary pointer, and MUST point to well defined memory location. It doesn't need to be in the managed heap, but it can't be a random pointer into the GC heap. I'll try to come up with some better wording
There was a problem hiding this comment.
It sounds like a managed pointer can contain any value that is not in the managed heap. In practice it needs to be zero or to allocated unmanaged space, etc., to avoid the possibility of it being in the managed heap (now by being captured by a future addition to the managed heap), though I suspect the details of how to guarantee a valid "unmanaged value" should be beyond the scope of this document.
Though now that I think about it, "not in the managed heap" seems too permissive. For example, pointers to the stack that are -not- to locals (e.g., to the return address) might be problematic for future implementations (e.g., stack segments), or pointers to internal unmanaged runtime data structures might have some special meaning in a hypothetical future implementation. So perhaps a better form of "not in the managed runtime" would capture the idea?
There was a problem hiding this comment.
Eh, pointers to the native stack are permitted, and we certainly have customers which rely on that behavior, but the notion of requiring the pointer to point at memory explicitly allocated from the native heap, or to a currently in use native stack activation frame might be a better way to describe these pointers.
Co-authored-by: Jan Kotas <jkotas@microsoft.com> Co-authored-by: Aaron Robinson <arobins@microsoft.com>
Attempt to address feedback.
Co-authored-by: Aaron Robinson <arobins@microsoft.com>
Fixes #69690