Mac OSX: parseNumber tests failing for out-of-bound numbers on clang about spirv-tools HOT 3 CLOSED

The reliance on the failure from istringstream is used to check for out-of-bounds arguments to things like OpConstant %type , where %type is a known type.
For example if %type is an unsigned 32-bit int, then the istringstream::fail() is used to see if the value is out of bounds for that type.
In short, this is behaviour we do want to rely on, so that the assembler can properly check its inputs.

This looks like a bug in the Apple C++ library.
Behaviour is as specified in http://en.cppreference.com/w/cpp/io/basic_istream/operator_gtgt
In particular "f extraction fails, zero is written to value and failbit is set. If extraction results in the value too large or too small to fit in value, std::numeric_limits::max() or std::numeric_limits::min() is written and failbit flag is set."

Well, we've already worked around a GNU libc++ bug. We seem to have an Apple one.

Thanks for reporting this.

from spirv-tools.

I investigated two test failures which occur on Mac OSX using Apple's Clang.

There are two failing essential cases:

1. parsing "-0" is expected to succeed with value 0 even for unsigned target types.
2. parsing a too-large floating point value in regular notation (e.g. 1.0e400) is expected to result in an error, but it does not.

from spirv-tools.

Fixed in master with 6bad02c

from spirv-tools.