-
Notifications
You must be signed in to change notification settings - Fork 1k
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.
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
Spec out numeric IntPtr #6031
Spec out numeric IntPtr #6031
Conversation
proposals/numeric-intptr.md
Outdated
For the predefined operators, the number of bits to shift is computed as follows: | ||
|
||
- When the type of `x` is `int`, **`nint`** or `uint`, the shift count is given by the low-order five bits of `count`. In other words, the shift count is computed from `count & 0x1F`. | ||
- When the type of `x` is `long`, **`nuint`** or `ulong`, the shift count is given by the low-order six bits of `count`. In other words, the shift count is computed from `count & 0x3F`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think nuint
belongs to the above category here #Resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't nuint
be masked to (sizeof(nuint) * 8) - 1
(0x3F
on 64-bit and 0x1F
on 32-bit)? If it's exclusively masked to 0x3F
it will become non-deterministic for what the computed result is when over shifting is involved on a 32-bit platform.
proposals/numeric-intptr.md
Outdated
nint operator <<(nint x, nint count); | ||
nuint operator <<(nuint x, nint count); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't count
be int
for consistency with the other shift operators?
Or is this including the relaxations from #4666 ? #Resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch. Bad search&replace ;-)
- `IntPtr - int` | ||
- `IntPtr -> int` | ||
- `long -> IntPtr` | ||
- `void* -> IntPtr` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this could overflow? Aren't these always the same size? #Resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
C# considered pointers as unsigned
, so this can technically overflow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup. Chuck caught that. It's covered in the breaking changes document and in OverflowPointerConversion
test.
proposals/numeric-intptr.md
Outdated
|
||
### Breaking changes | ||
|
||
One of the main impacts of this design is that `System.IntPtr` and `System.IntPtr` gain some built-in operators (conversions, unary and binary). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was one of these supposed to be UIntPtr
? #Resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed. Thanks
proposals/numeric-intptr.md
Outdated
|
||
## 8.8 Unmanaged types | ||
|
||
In other words, an __unmanaged_type__ is one of the following: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
|
||
# 11 Expressions | ||
|
||
#### 11.6.4.6 Better conversion target |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There would be a change inside the ellipsis ("Specifically: ..."), but I didn't spell it out. I think the general rule is clear enough.
|
||
\[...] The number of expressions in the *argument_list* shall be the same as the rank of the *array_type*, and each expression shall be of type `int`, `uint`, **`nint`, `nuint`**, `long`, or `ulong,` or shall be implicitly convertible to one or more of these types. | ||
|
||
#### 11.7.10.2 Array access |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
proposals/numeric-intptr.md
Outdated
|
||
For the predefined operators, the number of bits to shift is computed as follows: | ||
\[...] | ||
- When the type of `x` is `nint` or `nuint`, the shift count is given by the low-order five bits of `count` on a 32 bits platform, or the lower-order six bits of `count` on a 64 bits platform. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
proposals/numeric-intptr.md
Outdated
### Breaking changes | ||
|
||
One of the main impacts of this design is that `System.IntPtr` and `System.UIntPtr` gain some built-in operators (conversions, unary and binary). | ||
Those include `checked` operators, which means that some operators on those types will now throw when overflowing. For example: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think that's the complete list. How about multiplication?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Multiplication is not defined for IntPtr
with C#10.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point. Thanks
Fixed
proposals/numeric-intptr.md
Outdated
For the predefined operators, the number of bits to shift is computed as follows: | ||
\[...] | ||
- When the type of `x` is `nint` or `nuint`, the shift count is given by the low-order five bits of `count` on a 32 bits platform, or the lower-order six bits of `count` on a 64 bits platform. | ||
The shift count is computed from `count & (sizeof(nint) * 8 - 1)`, which is `count & 0x1F` on a 32 bits platform and `count & 0x3F` on a 64 bits platform. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
proposals/numeric-intptr.md
Outdated
|
||
## 8.8 Unmanaged types | ||
|
||
In other words, an **unmanaged_type** is one of the following: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Test plan dotnet/roslyn#60578