2^-14 fails to serialize on little-endian systems

[dgrigsby]

From here: http://tools.ietf.org/html/rfc7049#appendix-A There is this example: 0.00006103515625 -> 0xf90400
It turns out the left hand side is 2^-14. Using libcbor 0.3.1 on XCode simulator (little-endian), cbor_serialize_alloc fails after cbor_build_float2 for the provided number. Actually it appears to get into an endless loop until aborted by an illegal malloc request. Here's a function that demonstrates the issue:

• (void) testTwoToMinus14 { cbor_item_t* pItem = cbor_build_float2(0.00006103515625); unsigned char* buffer; size_t buffer_size, length = cbor_serialize_alloc(pItem, &buffer, &buffer_size); XCTAssert(length); }

Attached is an image showing my test program and the results.

[dgrigsby]

The problem appears to be in cbor_encode_half. "exp" is -14 (which is correct), represented in a byte as 0xf2. Then this is interpreted as passing the if (exp > 15) test at line 147. A zero is returned, which causes cbor_serialize_alloc to uselessly resize the buffer and try again. The screenshot below shows the sordid details.

[dgrigsby]

This may mean you can't encode any half-float between 0 and 0.5.

[PJK]

Hi @dgrigsby,

I'm not sure this problem has to do with endianess -- I've added all the examples to the test suite (075cdbf798145d2ebb6cefab3e684ade50521a22) and they seem to pass on x86 machines.

Could you please describe the complete setup/XCode config?

Thank you!

[PJK]

You were right, there was a problem in how the encoding works. Until there is a native way to represent half floats in C, it will remain a compromise, but I've updated the encoding so that it always produces a reasonable value.

49 together with #50 should resolve your issue.