[release/8.0-staging] UInt64.CreateSaturating<Int128> truncates instead of saturates #97047
Conversation
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
dotnet-issue-labeler
bot
added
the
needs-area-label
tannergooding
added
Servicing-consider
|
Tagging subscribers to this area: @dotnet/area-system-numerics Issue DetailsBackport of #96369 to release/8.0-staging /cc @tannergooding @pedrobsaila Customer ImpactDevelopers attempting to use generic math to convert an TestingAdditional tests covering the edge case was added. RiskLow. The general pattern is already established and this was using the wrong one (conversion to a smaller type use one pattern, conversion to a larger type use a different pattern), likely due to a copy/paste error when covering the full set of integral types that needed the code.
|
|
FYI - This will have to wait until the March release. Code Complete for the February Release is today and I'm already starting the flow to internal. |
|
I missed you by a few minutes, @carlossanlop -- but understood. Thanks for the heads-up. |
carlossanlop
added
Servicing-approved
|
Approved by Tactics via email. We can get this into Feb. |
Backport of #96369 to release/8.0-staging
/cc @tannergooding @pedrobsaila
Customer Impact
As reported by a customer, attempting to use generic math to convert an
Int128to aUInt64using saturation may see incorrect results. This conversion uses truncation behavior instead of saturation. For example,ulong.CreateSaturating((Int128)ulong.MaxValue + (Int128)10L))returns9instead ofulong.MaxValue(18446744073709551615).The customer found and illustrated scenarios/types where the correct behavior exists, comparing this to types where the incorrect behavior is present. This bug results in unexpected arithmetic results, which can cause data correctness issues in applications. More details can be found in #94523, where this was reported.
Regression
No. The bug exists back to .NET 7.
Testing
Additional tests covering the edge case were added.
Risk
Low. The general pattern is already established and this was using the wrong one (conversion to a smaller type use one pattern, conversion to a larger type use a different pattern), likely due to a copy/paste error when covering the full set of integral types that needed the code.