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 (075cdbf) 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.