| 1 | /* |
| 2 | * Copyright (C) 2014 Apple Inc. All rights reserved. |
| 3 | * |
| 4 | * Redistribution and use in source and binary forms, with or without |
| 5 | * modification, are permitted provided that the following conditions |
| 6 | * are met: |
| 7 | * 1. Redistributions of source code must retain the above copyright |
| 8 | * notice, this list of conditions and the following disclaimer. |
| 9 | * 2. Redistributions in binary form must reproduce the above copyright |
| 10 | * notice, this list of conditions and the following disclaimer in the |
| 11 | * documentation and/or other materials provided with the distribution. |
| 12 | * |
| 13 | * THIS SOFTWARE IS PROVIDED BY APPLE INC. ``AS IS'' AND ANY |
| 14 | * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE |
| 15 | * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR |
| 16 | * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL APPLE INC. OR |
| 17 | * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, |
| 18 | * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, |
| 19 | * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR |
| 20 | * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY |
| 21 | * OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT |
| 22 | * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE |
| 23 | * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. |
| 24 | */ |
| 25 | |
| 26 | #pragma once |
| 27 | |
| 28 | #include <wtf/Assertions.h> |
| 29 | #include <wtf/StdLibExtras.h> |
| 30 | |
| 31 | namespace JSC { |
| 32 | |
| 33 | // NaN (not-a-number) double values are central to how JavaScriptCore encodes JavaScript |
| 34 | // values (JSValues). All values, including integers and non-numeric values, are always |
| 35 | // encoded using the IEEE 754 binary double format. Non-double values are encoded using |
| 36 | // a NaN with the sign bit set. The 51-bit payload is then used for encoding the actual |
| 37 | // value - be it an integer or a pointer to an object, or something else. But we only |
| 38 | // make use of the low 49 bits and the top 15 bits being all set to 1 is the indicator |
| 39 | // that a value is not a double. Top 15 bits being set to 1 also indicate a signed |
| 40 | // signaling NaN with some additional NaN payload bits. |
| 41 | // |
| 42 | // Our use of NaN encoding means that we have to be careful with how we use NaNs for |
| 43 | // ordinary doubles. For example, it would be wrong to ever use a NaN that has the top |
| 44 | // 15 bits set, as that would look like a non-double value to JSC. |
| 45 | // |
| 46 | // We can trust that on all of the hardware/OS combinations that we care about, |
| 47 | // NaN-producing math operations never produce a NaN that looks like a tagged value. But |
| 48 | // if we're ever in a situation where we worry about it, we can use purifyNaN() to get a |
| 49 | // NaN that doesn't look like a tagged non-double value. The JavaScript language doesn't |
| 50 | // distinguish between different flavors of NaN and there is no way to detect what kind |
| 51 | // of NaN you have - hence so long as all double NaNs are purified then our tagging |
| 52 | // scheme remains sound. |
| 53 | // |
| 54 | // It's worth noting that there are cases, like sin(), that will almost produce a NaN |
| 55 | // that breaks us. sin(-inf) returns 0xfff8000000000000. This doesn't break us because |
| 56 | // not all of the top 15 bits are set. But it's very close. Hence our assumptions about |
| 57 | // NaN are just about the most aggressive assumptions we could possibly make without |
| 58 | // having to call purifyNaN() in surprising places. |
| 59 | // |
| 60 | // For naming purposes, we say that a NaN is "pure" if it is safe to tag, in the sense |
| 61 | // that doing so would result in a tagged value that would pass the "are you a double" |
| 62 | // test. We say that a NaN is "impure" if attempting to tag it would result in a value |
| 63 | // that would look like something other than a double. |
| 64 | |
| 65 | // Returns some kind of pure NaN. |
| 66 | inline double pureNaN() |
| 67 | { |
| 68 | // Be sure that we return exactly the kind of NaN that is safe. We engineer the bits |
| 69 | // ourselves to ensure that it's !isImpureNaN(). FWIW, this is what |
| 70 | // numeric_limits<double>::quiet_NaN() returns on Mac/X86_64. But AFAICT there is |
| 71 | // no guarantee that quiet_NaN would return a pureNaN on all platforms. For example, |
| 72 | // the docs appear to imply that quiet_NaN could even return a double with the |
| 73 | // signaling bit set on hardware that doesn't do signaling. That would probably |
| 74 | // never happen, but it's healthy to be paranoid. |
| 75 | return bitwise_cast<double>(0x7ff8000000000000ll); |
| 76 | } |
| 77 | |
| 78 | #define PNaN (pureNaN()) |
| 79 | |
| 80 | inline bool isImpureNaN(double value) |
| 81 | { |
| 82 | // Tests if the double value would break JSVALUE64 encoding, which is the most |
| 83 | // aggressive kind of encoding that we currently use. |
| 84 | return bitwise_cast<uint64_t>(value) >= 0xfffe000000000000llu; |
| 85 | } |
| 86 | |
| 87 | // If the given value is NaN then return a NaN that is known to be pure. |
| 88 | inline double purifyNaN(double value) |
| 89 | { |
| 90 | if (value != value) |
| 91 | return PNaN; |
| 92 | return value; |
| 93 | } |
| 94 | |
| 95 | } // namespace JSC |
| 96 | |