Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Library version able to parse float lacking decimal? #726
We're using ArduinoJson on an AVR platform for the ATmega2560. Our release code is built with avr-gcc 4.9.4. Our unit tests are cross compiled in a Linux environment using gcc 4.9.4. We're a number of versions behind on the ArduinoJson library itself at version 5.5.1.
We hit a bump today and are trying to determine the best course of action. We discovered in our on-target release build and in our unit tests that a numeric JSON value lacking a decimal (e.g. 2 instead of 2.0) parsed as a float erroneously returns 0.
Experiments with the offending line of code using the latest version of ArduinoJson in Wandbox with our version of gcc suggests this is no longer a problem (assuming it truly was).
More than 700 questions have been posted to this day and this is one of the most surprising
I don't remember why this version behaved that way, but it sure treated floats and integer differently than today.
In any case, I strongly recommend that you upgrade to version 5.13.
We have a number of embedded devices in use whose application code is built with ArduinoJson 5.5.1. We've written a lot of code around ArduinoJson 5.5.1, and it's been in use for years at this point. A new use case developed recently where we began introducing more floating point values into the JSON being processed. Things started breaking. To our surprise we identified it being the absence of a decimal point in numeric entries in the JSON.
We were hesitant to update to a far newer version of the library without first consulting the author. Updating to the new library could be quite a significant amount of coding work plus updating deployed systems and potentially introduce unforeseen instabilities. We know 5.5.1 and apart from this decimal issue we are quite comfortable with it. We did, in fact, consult the Changelog, but we weren't able to determine if the changes between 5.5.1 and 5.13.1 fixed our issue or what kind of work would be necessary to update existing code.
So… I just now went ahead and rebuilt our code and re-ran unit tests with 5.13.1 as an experiment. To my great surprise and relief the problem is solved, no code rewrites were needed, and only a single compiler flag change was necessary for the release build! We still need to do the appropriate packaging, documentation, and validation testing before deployment, but I am so very pleased to see these results.
Some thank you's:
We can close this issue.
Thank you again.