1.0.1

• Fixed issue with spec-compliance
• Very minor performance optimization (<1%)

1.0

Even though this is 1.0, it only saw very small, technical changes.

I'm releasing this as 1.0 because I have some plans that introduce way more complexity into the library and developing those features can (and will) introduce instability and performance problems.

I will however still fix bugs as they are found in 1.0.

Changelog:

• Moved some code around for "free" but minimal performance gains
• Removed some dead / useless code
• Deduplicated the reset-handling
• Got rid of the manual value length counting
• Optimized a parser-state distinction
• Fixed a memory leak
• Got rid of some unused allocations.

0.20.2

• Fixed memory issues
• Sped up trimming.

0.20.1

Just a small release:

• Propagate errors up the tree. Makes errorhandling quite a bit easier on the users end.

• Fixed an off-by-one error in error message generation. Now it should always include the correct line and column number.

• Small improvement in LET(): Allocate all of _children at once.

• Small improvements in stringfunctions.bi: Try to avoid more allocations, more aggressive use of byref to avoid copying data around.

0.20

• Fixed inconsistency with duplicate keys
• Performance:
  • Improved UTF-8 validation
  • number validation (numbers without periods and exponents no longer rely on CDBL)
  • Various speedups in parse()
  • Allocate 2 children at a time to cut down on costly realllocations

RFC compliance!

I decided to run the tests from https://github.com/nst/JSONTestSuite and had more than 60 tests fail on me.

I fixed all tests with the "y_" or "n_" prefix. This affects:

• Number validation (again!). Some of those were extreme edgecases, like "0e+1" not passing.
• How object closure is handled: Stuff like [1]] wasn't malformed
• String validation. Unescaped control characters (bytes 1 to 31) are now treated as unexpected tokens when within quotes.
• Dangling commas are now handled (i.e. [1,] and {"foo": 1,}
• \u0000 will now be deescaped. Be careful with that.
• Excess characters after the valid JSON will now be an error. IE. [18.1]#
• While deescaping, missing surrogates will now reliably cause errors

If you relied on some of the above mentioned, check your JSON files.

Also: Defining fbJson_Debug will no longer exit the program when encountering an error.

0.18

• Improved de-escaping and fixed various edgecases
• Improved validation of numbers
• Fixed several bugs in jsonItem.AddItem()
• Made fbJson bit easier to use as DLL / Library
• Added a couple of examples.

Also some work on performance to mitigate the losses caused by more checks. Still ended up a bit faster than 0.17. :)

Unless I missed a bug, I think I'm compliant with the specifications now. Only thing left for 1.0 is testing and maybe incorporating some user feedback.

0.17.1: Fixed deescaping bug.

• Fixed deescaping of "\\foo"
• Fixed an off-by-one error in number parsing.
• Fixed some memory related issues (deallocation in error cases, invalid write, ...)

0.17

Bugfixes, spec compliance and usage:

• Fixed UTF-8 validation
• Added clearer error messages to UTF-8 related errors
• Fixed some minor memory issues (invalid read / write)
• Fixed issue with object reuse
• Fixed segfault when calling constructor with empty string
• ToString() now 'writes' flat values
• Added getError() to actually read the error messages generated by the parser
• Removed JsonDocument

Internal:

• Separated JsonBase from JsonItem (doesn't affect use)
• Separated header files from actual code.

0.16

• Saner errorhandling, including way better errormessages.
  • the datatype "malformed" (-1) now propagades down the JSON tree.
• Key strings are now de-escaped
• Deescaping can resolve UTF-16 surrogate pairs (i.e. \uD83E\uDDC0 will be resolved to 🧀)
• Some primitive UTF-8 validation (everything in a JSON file must be valid utf-8)

Small performance tweaks:

• Parsing of the \u-notation is sped up by ~30%
• Swapped out FBs instr() with isInString() to sped up search for "" in keys and strings.

Due to the changes in error-handling, some JSON inputs that were previously parsed just fine might break now (correctly or not). Please report any valid JSON that gets rejected.