Open
Bug 1398755
Opened 7 years ago
Updated 2 years ago
Add a way to detect whether a Nan is signalling
Categories
(Core :: MFBT, enhancement, P3)
Core
MFBT
Tracking
()
NEW
People
(Reporter: Yoric, Unassigned)
Details
It would sometimes be useful to determine whether a value is a signalling NaN. Could we add this to mfbt/FloatingPoint.h?
Comment 1•7 years ago
|
||
In principle, probably -- but what's the actual use case? Generally sNaNs are supposed to make everything break the second you do something with them, by design. And I'd have figured an existing use would have broken for just this reason already.
Reporter | ||
Comment 2•7 years ago
|
||
In my specific use case, I am deserializing NaNs from a binary stream. I want to be able to reject signalling NaNs, specifically before they break stuff. At the moment, I am doing this manually, which is a bit ugly.
Comment 3•7 years ago
|
||
Ah, yes, I've caught up to the BinJS bug in my bugmail backlog now. :-) It seems sensible -- although maybe finicky? I would presume sNaN is an architecture-specific thing, so may be tricky to recognize purely by looking for one particular sort of bit pattern at compile time. That said, at a super-cursory glance, might be better/easier for all NaNs to be considered as one there, just as JS itself does. It isn't immediately obvious to me why a one-to-one compression/translation of JS would have NaNs in it with any sort of custom bit pattern, given you can only get those in real JS through punning on ArrayBuffers, and that practice wouldn't show up at the source code level.
Comment 4•7 years ago
|
||
I personally would have no problem adding this, but there would be some grotty architectural-specific ifdefs involved. I think you'd also want to note the trail of sadness in Casting.h for BitwiseCast and *not* do this on actual floating-point values.
Priority: -- → P3
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•