Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Describe the validity of null managed pointers #71794

Merged
merged 4 commits into from
Aug 2, 2022
Merged

Describe the validity of null managed pointers #71794

Changes from 1 commit
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
b3b6174
Describe the validity of null managed pointers
davidwrighton Jul 7, 2022
636b7ea
Apply suggestions from code review
davidwrighton Aug 1, 2022
9ff3f4d
Update Ecma-335-Augments.md
davidwrighton Aug 2, 2022
4cc1fa0
Update docs/design/specs/Ecma-335-Augments.md
davidwrighton Aug 2, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 10 additions & 0 deletions docs/design/specs/Ecma-335-Augments.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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)."
davidwrighton marked this conversation as resolved.
Show resolved Hide resolved
davidwrighton marked this conversation as resolved.
Show resolved Hide resolved
- 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."
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would be explicit in the previous sentence and simply state managed pointers may be null.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


Changes to signatures:
### II.23.2.10
- Remove special case for TYPEDBYREF
Expand All @@ -997,6 +1001,12 @@ Changes to signatures:
### II.23.2.12
- Add TYPEDBYREF as a form of Type

### III.1.1.5.2
- Replace "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, 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)."
- Remove the sentence "Managed pointers cannot be null."
- Add a bullet point
- Managed pointers which point at null, 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, are considered to be an invalid address.
davidwrighton marked this conversation as resolved.
Show resolved Hide resolved

## Rules for IL Rewriters

There are apis such as `System.Runtime.CompilerServices.RuntimeHelpers.CreateSpan<T>(...)` which require that the PE file have a particular structure. In particular, that api requires that the associated RVA of a FieldDef which is used to create a span must be naturally aligned over the data type that `CreateSpan` is instantiated over. There are 2 major concerns.
Expand Down