Note that NaN has multiple binary représentations, some of them designed as "signaling" and others non-signaling. The signaling bit uses only 1 bit in the mantissa, that must not be all ones, leaving more than 50 bits for other information, such as the cause of a NaN to be generated. These bits are used variable depending on hardware FPU or emulation librairies. Note as well that NaN incluses the sign bit as the most signifiant bit of the mantissa, but the signaling bit is just the next one. Then the next bit can be set to 0, to distinguish a non-signaling NaN from plus or minus Infinity.
In Java, all these NaN values are unified to a single value. Some libraries are also unifying the sign of zeroes, forcing it to be "positive". So finally there remains only two binary-encoded FP values that can have their exponent part set to its minimum value, à single zero and a single NaN treated as no' signaling.
This is important to note if you serialize FP values in binary form, in order for example to generate digital signatures. Not all C librairies or compiler make effort to unify FP zeroes or NaNs. Some are also reducing possible "denormalized" numbers to zero, preserving their sign in the FP signed zero, or dropping it completely.
So how extra bits in NaN (including the sign bit) or the extra sign bit of FP zero is usable or not remains platforms dépendant. For librairies that recognize these bits as signifiant, minus zero is distinct when compared for strict identity, but usually not for numeric comparators, eg used for sorting or matching keys in hashed tables. And a text representation of NaN may display à negative sign and an extension after "NAN", usually in parentheses and showing the extra bits usually as a decimal integer within these parentheses. Some librairies that have semantics for signaling NANs may also use an "!" character after the "NaN" constant but before the extension in parentheses
