This is an attempt at improving the CFNumber checker which catches disagreements between the programmer-declared CFNumberType of the value (e.g., kCFNumberSInt16Type) and its actual type (hopefully a signed short).
The existing code only checked the expected number of bits. However, there are other ways this could go wrong, such as passing a double where a 64-bit integer is expected, or accidentally interpreting an unsigned integer as a signed integer.
I consider the set of CFNumberTypes as two categories: regular numeric types that map cleanly to standard C data types, such as SInt8, Float, LongLong, etc., and special named types such as CFIndex, NSInteger, and Float32 (which is not necessarily a IEEE 754 float).
For numeric types, they need only agree in signedness, bit width, and numeric type (integer vs real).
For the special named types, I don't want to allow passing, for instance, an int when kCFNumberCFIndexType is specified—that might work without issue on 32-bit, but on 64-bit there will be an overflow. So for these named types, I want to make sure that you are actually passing a CFIndex value (or something typedef'd to CFIndex).
I also extended it to also check CFNumberGetValue, which has the same issues as CFNumberCreate.
The checker is incomplete (for instance, I'd welcome feedback on how the diagnostics should be written) but I'm posting here for some early feedback.
Since it handles floating point values as well, this function is misnamed.