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.

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

Floating-point to byte conversions are unchanged #44621

Open
joelawryshort opened this issue Jan 30, 2025 · 1 comment
Open

Floating-point to byte conversions are unchanged #44621

joelawryshort opened this issue Jan 30, 2025 · 1 comment
Assignees
Labels
breaking-change Indicates a .NET Core breaking change dotnet-fundamentals/svc okr-quality Content-quality KR: Concerns article defects (bugs), freshness, or build warnings.

Comments

@joelawryshort
Copy link

joelawryshort commented Jan 30, 2025

Type of issue

Missing information

Description

This change was made to standardize all floating point-to-integer conversions

It looks like floating point to byte/sbyte conversions are unaffected in .NET 9 (see fiddle). Should this be mentioned explicitly?

Page URL

https://learn.microsoft.com/en-us/dotnet/core/compatibility/jit/9.0/fp-to-integer

Content source URL

https://github.com/dotnet/docs/blob/main/docs/core/compatibility/jit/9.0/fp-to-integer.md

Document Version Independent Id

94cb081e-0c73-76b9-c756-ea5f779c5c28

Article author

@CamSoper

Metadata

  • ID: 49ffed11-e4a2-7096-8a2f-e5490dda89dd
  • Service: dotnet-fundamentals

Related Issues

@dotnet-policy-service dotnet-policy-service bot added the ⌚ Not Triaged Not triaged label Jan 30, 2025
@CamSoper CamSoper self-assigned this Jan 30, 2025
@CamSoper CamSoper added breaking-change Indicates a .NET Core breaking change okr-quality Content-quality KR: Concerns article defects (bugs), freshness, or build warnings. and removed ⌚ Not Triaged Not triaged labels Jan 30, 2025
@joelawryshort
Copy link
Author

joelawryshort commented Jan 30, 2025

I was provided with more information about this here.

Conversion behaviour from floating-point types to "small" integral types (e.g. byte, short) is undefined, and is therefore not guaranteed to use the new saturating behaviour. Depending on the platform, floating-point numbers are often first converted to 32-bit integers before being converted to the target "small" integral type.

On the platforms I have tested, the first step now uses saturating arithmetic, but the second part remains truncating, resulting in mixed behaviour above and below the boundary of the max value of a 32-bit integer. For example the double value of 256001.0 truncates to a byte value of 1, but any value greater than or equal to 2147483647.0 saturates to 255.

Edit: added detail and precision about the behaviour being undefined.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking-change Indicates a .NET Core breaking change dotnet-fundamentals/svc okr-quality Content-quality KR: Concerns article defects (bugs), freshness, or build warnings.
Projects
None yet
Development

No branches or pull requests

2 participants