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

Inconsistent reporting of numbers that are too big to be stored in a double #849

Closed
kahatlen opened this Issue Feb 10, 2017 · 1 comment

Comments

Projects
None yet
3 participants
@kahatlen

kahatlen commented Feb 10, 2017

If a JSON document contains a floating-point number that is too big to be stored in a double, RapidJSON sometimes raises an error that says "Number too big to be stored in double", and other times it silently accepts it and returns positive or negative infinity. It would be better if it consistently reported an error when it encountered a number that was too big.

Take this test program:

#include <iostream>
#include "rapidjson/error/en.h"
#include "rapidjson/error/error.h"
#include <rapidjson/reader.h>
#include <rapidjson/stream.h>

using namespace rapidjson;

class Handler : public BaseReaderHandler<UTF8<> > {
public:
  bool Double(double d) {
    std::cout << d;
    return true;
  }
};

void test(const char* json) {
  std::cout << json << " -> ";
  Reader reader;
  StringStream stream(json);
  Handler handler;
  if (!reader.Parse(stream, handler)) {
    std::cout << GetParseError_En(reader.GetParseErrorCode());
  }
  std::cout << std::endl;
}

int main() {
  test("3.14");
  test("1e308");
  test("1.7e308");
  test("1.8e308");
  test("5e308");
  test("1e309");
  test("1.0e310");
  test("1.00e310");
  test("-1.7e308");
  test("-1.8e308");
  test("-1e309");
}

With g++ 6.3.0 on Debian 9 (amd64), I see the following output:

3.14 -> 3.14
1e308 -> 1e+308
1.7e308 -> 1.7e+308
1.8e308 -> inf
5e308 -> inf
1e309 -> Number too big to be stored in double.
1.0e310 -> Number too big to be stored in double.
1.00e310 -> inf
-1.7e308 -> -1.7e+308
-1.8e308 -> -inf
-1e309 -> Number too big to be stored in double.

It would be more consistent if those cases that currently say "inf" or "-inf" said "Number too big" instead.

@miloyip miloyip added the bug label Feb 12, 2017

@StilesCrisis

This comment has been minimized.

Contributor

StilesCrisis commented Mar 15, 2017

I tested this with the Full Precision flag but it actually made matters worse. The "inf" entries became garbage:

nan
-8.6927218887537693e-309
-3.0943460473825783e-307
nan

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment