Numbers like 1.0 were being encoded as <<"1">> which can lead to a bit
of confusion. This merely checks if a decimial point exists and if not
it appends ".0" to the value.
I need to fix this so that object sizes don't explode when generating
larger values. Basically, as the type generator recurses is should be
adjusting the size value.
Looks like there's a slight difference in the number of significant
digits supported across platforms in strtod. This just adds a couple to
force it into the bignum code.
Big thanks to Dmitry Groshev [1] for help getting PropEr tests into
Jiffy. These generate valid EJSON to check parsing as well as check
that random inputs don't cause segfaults or other nasty effects.
Future improvements would be to write a JSON generator as well as a
version that introduces known errors into the binary for checking known
parsing errors as well.
[1] https://github.com/si14Fixes: #10
Rebar's eunit command wants to try and compile anything named *.erl in
the tests/ directory which causes errors with the test expectation
files. Rather than write a patch for rebar it was easier to just rename
everything.
It was possible to pass some types of invalid UTF-8 through Jiffy's
encoder. Specifically, if uescaping isn't used, values that would decode
from 0xD800 to 0xDFFFF, 0xFFFE, 0xFFFF, and values greater than 0x10FFFF
would not be flagged as invalid. Now they are.
Based on the buffer doubling scheme in Yajl. This seems to make
Jiffy's encoder times less spikey, but I'm still a bit slower. It
appears to be related to floats or memory handling. Not sure how
to track this down.
The encoder can now return \u escaped unicode data instead of leaving
it as UTF-8 byte sequences. This done like so:
Eshell V5.8.3 (abort with ^G)
1> jiffy:encode(<<240, 144, 129, 128>>, [uescape]).
<<"\"\\uD800\\uDC40\"">>
The encode and decode functions now return the value directly without
being wrapped in a tuple on success. If there is an error, it is
thrown. This is to more closely match the semantics of term_to_binary
and binary_to_term.
Any number that can't be decoded in C is now passed back
to Erlang for decoding.
Large numbers passed to the encoder will make it through
and be processed in Erlang after the main encoding
process.
* Refs became atoms to make sure they can live across calls
to the NIF functions.
* Initialized curr in decode so that I'm no longer pushing
random values into the Erlang VM.