| Summary: | json-c: double handling issues (accuracy, thread safety) | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Florian Weimer <fweimer> |
| Component: | json-c | Assignee: | Remi Collet <rcollet> |
| Status: | CLOSED WONTFIX | QA Contact: | BaseOS QE - Apps <qe-baseos-apps> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.0 | CC: | jorton |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-12-17 10:36:02 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Bug Depends On: | |||
| Bug Blocks: | 1028485 | ||
Decoding is not thread-safe because it switches the process LC_NUMERIC locale to C temporarily. I strongly suspect this is done for the benefit of double parsing with sscanf, so it is related to this issue. The accuracy issue is addressed in this upstream commit (assuming that "17" is large enough to preserve all digits, I haven't checked that). https://github.com/json-c/json-c/commit/06450206c4f3de4af8d81bb6d93e9db1d5fedec1 Reported upstream: https://github.com/json-c/json-c/issues/195 |
json_object_double_to_json_string() uses the %f conversion specifier to convert a double to a string: size = snprintf(buf, 128, "%f", jso->o.c_double); p = strchr(buf, ','); if (p) { *p = '.'; } else { p = strchr(buf, '.'); } This is lossy, it does not preserve all significant digits. Exact conversion between binary and decimal floating point is difficult, and json-c should probably use gdtoa or grisu to implement this. That would ensure nice-looking but accurate output, but it's a lot of code. There is a width (18?) that ensures that %s is completely accurate, but I don't have the details at hand right now. The decimal comma rewriting is also a bit suspect, but I couldn't get it to fail in a fa_IR locale (which is supposed to have neither a decimal point nor a decimal comma).