DoubleBits, avoid garbage value

[nilason]

After the merging of the PR #238, there remain only one issue checking with xcode static analyser (xcode 10.2.1):

/geos/src/index/quadtree/DoubleBits.cpp:144:11: warning: The left expression of the compound assignment is an uninitialized value. The computed value will also be garbage
    xBits &= mask;
    ~~~~~ ^
/geos/src/index/quadtree/DoubleBits.cpp:152:19: warning: The left operand of '&' is a garbage value
    return (xBits & mask) != 0 ? 1 : 0;
            ~~~~~ ^
2 warnings generated.

This fix addresses this.

[dbaston]

I don't think this is the right fix. Isn't 0 just a different garbage value? xBits isn't initialized when ASSUME_IEEE_DOUBLE isn't defined, so we probably shouldn't be reading from it in that case either. Or we could simply do a static assert for IEEE compliance and remove the other code pathways.

[nilason]

You make a very good point there. Indeed, __STDC_IEC_559__ is not defined by all compilers and isn't a fool-proof check for IEEE compliance. This is the case with clang (thus the warnings).

Or we could simply do a static assert for IEEE compliance and remove the other code pathways.

This seems to me to be the preferable solution, although I'm afraid I cannot help out on that.

[nilason]

Couldn't resist attempting to fix this using static_assert, with latest pushed commit. Seems to be fine with CI's.

(note: if it comes to merge, I need to clean up commit history before)

[pramsey]

So, coming back to this, the final patch is brutal in its simplicity but it also forecloses working on any platform that doesn't have ieee754... which is... which platforms? I mean, I'd like to know what doors we're closing with this. Also, we're only closing them for what? To shut up a static analyzer?

[abellgithub]

It looks like much of this code isn't used, and what is used can be replaced by library calls, I think.

[pramsey]

Seems like, trying in #317