Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[question]: macro to disable floating point support #284

Closed
rianquinn opened this issue Jul 21, 2016 · 6 comments
Closed

[question]: macro to disable floating point support #284

rianquinn opened this issue Jul 21, 2016 · 6 comments
Labels
kind: enhancement/improvement solution: wontfix the issue will not be fixed (either it is impossible or deemed out of scope)

Comments

@rianquinn
Copy link

We are interested in using JSON in our Bareflank Hypervisor for both comms and configuration files, and would love to use this implementation. Kernel / Hypervisor code however should not use double / float as these data types can generate exceptions that cannot be handled well inside the kernel.

It appears that you already support signed / unsigned integers. Would you be interested in a patch that disables (likely via a macro of some sort) double / float completely to support people interested in using this library in non-userspace code?

@nlohmann
Copy link
Owner

Hi @rianquinn, this sounds interesting!

Did you see this paragraph in the README which could be relevant?

As the exact type of a number is not defined in the JSON specification, this library tries to choose the best fitting C++ number type automatically. As a result, the type double may be used to store numbers which may yield floating-point exceptions in certain rare situations if floating-point exceptions have been unmasked in the calling code. These exceptions are not caused by the library and need to be fixed in the calling code, such as by re-masking the exceptions prior to calling library functions.

How would you deactivate floating-point support? Did you try setting number_float_t to a different type? If possible, I would like to avoid getting to the #ifdef-hell...

@rianquinn
Copy link
Author

The perfect solution would prevent float / double types / instructions from being compiled into the code. The reality is, so long as the code is not executed, it's fine. I did not try setting number_float_t to a different type, but my guess is it would collide with your existing unsigned / signed ints. The question is, When a JSON string is read, and it sees a "42" and not a "42.0" does it use ints and not floats from start to finish? So long as floats and doubles are never used, it should be fine.

@nlohmann
Copy link
Owner

You're right - setting number_float_t to an integer type yields collisions. So far, I do not see a simple solution to exclude any floating-point numbers from the class.

@nlohmann
Copy link
Owner

Any idea how to proceed on this?

@rianquinn
Copy link
Author

rianquinn commented Aug 10, 2016

I think the best thing to do is probably close the ticket. A couple of days ago I grabbed the source and gutted anything with "float" or "double". It only took about 5 mins, and the resulting code worked great. Based on those results, this implementation is perfect for what we need it for, but the only way I know to implement this more generically is to use #defines which I would agree would clutter what you have for a very small use case. For now, my plan is to maintain a fork with the modifications in our repo. I'm watching this repo, so anytime you roll a release, I'll make the mods, and push to our repo, and let you know if anything you guys change breaks what we are doing. But yeah, I wrote the https://github.com/QtMark/qmjson code, and I really like what you have done with this C++ only implementation so we will use it for sure.

@nlohmann
Copy link
Owner

This is fine with me. Thanks for the quick response, and maybe we find way to cope with your usecase in a general way!

@nlohmann nlohmann added the solution: wontfix the issue will not be fixed (either it is impossible or deemed out of scope) label Aug 10, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind: enhancement/improvement solution: wontfix the issue will not be fixed (either it is impossible or deemed out of scope)
Projects
None yet
Development

No branches or pull requests

2 participants