-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
CBOR Writer: Use canonical NaN representation for NaN values #92934
Conversation
Tagging subscribers to this area: @dotnet/area-system-security, @bartonjs, @vcsjones Issue DetailsRFC 7049 (CBOR) specifies "If NaN is an allowed value, it must always be represented as 0xf97e00". The only exception I made is when the user explicitly requests precision (FP size) is preserved. The problem occurred for x86, C# defines NaN as 0.0/0.0 which yields -NaN on x86 FP units, which gets encoded as 0xf9fe00. Fixes issue #92080 Also, use positive NaNs on RISC-V for FP ops crossgen-evaluated when host is x86. Part of #84834
|
Tagging subscribers to this area: @dotnet/area-system-formats-cbor, @bartonjs, @vcsjones Issue DetailsRFC 7049 (CBOR) specifies "If NaN is an allowed value, it must always be represented as 0xf97e00". The only exception I made is when the user explicitly requests precision (FP size) is preserved. The problem occurred for x86, C# defines NaN as 0.0/0.0 which yields -NaN on x86 FP units, which gets encoded as 0xf9fe00. Fixes issue #92080 Also, use positive NaNs on RISC-V for FP ops crossgen-evaluated when host is x86. Part of #84834
|
0df3b49
to
f704df9
Compare
src/libraries/System.Formats.Cbor/src/System/Formats/Cbor/Writer/CborWriter.Simple.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Formats.Cbor/src/System/Formats/Cbor/Writer/CborWriter.Simple.cs
Outdated
Show resolved
Hide 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.
The JIT change LGTM.
src/libraries/System.Formats.Cbor/tests/Writer/CborWriterTests.Simple.netcoreapp.cs
Show resolved
Hide resolved
src/libraries/System.Formats.Cbor/src/System/Formats/Cbor/Writer/CborWriter.Simple.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Formats.Cbor/src/System/Formats/Cbor/Writer/CborWriter.Simple.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Formats.Cbor/src/System/Formats/Cbor/Writer/CborWriter.Simple.cs
Show resolved
Hide resolved
RFC 7049 (CBOR) specifies "If NaN is an allowed value, it must always be represented as 0xf97e00". The only exception is when the user explicitly requests precision (FP size) is preserved. The problem occurred for x86, C# defines NaN as 0.0/0.0 which yields -NaN on x86 FP units, which gets encoded as 0xf9fe00. Fixes issue dotnet#92080
…t patterns are still readable as NaN.
5bc3915
to
6dcb532
Compare
NaNs only get written as 4 or 8 bytes only in CTAP2 mode, which requires to preserve all bits anyway. + review fixes
6dcb532
to
69b97e9
Compare
...libraries/System.Formats.Cbor/src/System/Formats/Cbor/Writer/CborWriter.Simple.netcoreapp.cs
Show resolved
Hide resolved
Originally a race condition exists in `CheckDefaultProvider` and leads to wrong results when many methods are called simultaneously. The PR fixes that by extending the lock statement. Fix dotnet#92934
RFC 7049 (CBOR) specifies "If NaN is an allowed value, it must always be represented as 0xf97e00". The only exception I made is when the user explicitly requests precision (FP size) is preserved.
The problem occurred for x86, C# defines NaN as 0.0/0.0 which yields -NaN on x86 FP units, which gets encoded as 0xf9fe00.
Fixes issue #92080
Also, use positive NaNs on RISC-V for FP ops crossgen-evaluated when host is x86.
Part of #84834
cc @wscho77 @HJLeee @JongHeonChoi @t-mustafin @alpencolt @gbalykov @clamp03 @sirntar @yurai007