reading max double, throws bad conversion

[GoogleCodeExporter]

What steps will reproduce the problem?

#include <fstream>
#include <iostream>
#include <yaml-cpp/yaml.h>
using namespace std;

int main()
{
  double doubleVal;
  float floatVal;
  ofstream outYaml;
  YAML::Node writer;
  YAML::Node reader;

  // write
  writer["float"] = numeric_limits<float>::max();
  writer["double"] = numeric_limits<double>::max();
  outYaml.open("test.yaml");
  outYaml << writer;
  outYaml.close();

  // read
  reader = YAML::LoadFile("test.yaml");
  if (reader["float"])
  {
    floatVal = reader["float"].as<float>();
    cout << "float " << floatVal << endl;
  }
  if (reader["double"])
  {
    doubleVal = reader["double"].as<double>(); // throws bad conversion
    cout << "double " << doubleVal << endl;
  }
  return 0;
}

What is the expected output? What do you see instead?
reading max float is ok, but reading max double throws bad conversion

What version of the product are you using? On what operating system?
Using yaml-cpp 0.5.1 on Ubuntu 12.04 64-bit

Please provide any additional information below.

Original issue reported on code.google.com by lucky13...@gmail.com on 13 Dec 2013 at 7:36

[GoogleCodeExporter]

Original comment by lucky13...@gmail.com on 13 Dec 2013 at 8:14

Attachments:

• test.yaml

[GoogleCodeExporter]

Original comment by jbe...@gmail.com on 13 Dec 2013 at 9:05

• Changed state: Accepted

[GoogleCodeExporter]

I can't replicate this on OS X 10.9.5 with clang version:

Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin13.4.0
Thread model: posix

Instead, I get the output:

float 3.40282e+38
double inf

which sounds reasonable to me (i.e., there's loss when writing max double, and 
so it gets read as infinity).

I verified this both at the tip and at 0.5.1.

I hate to pull "works on my machine", but... works on my machine. Do you have 
any other debugging info to go on? Maybe post the stack trace of the exception?

Original comment by jbe...@gmail.com on 24 Jan 2015 at 11:47

[GoogleCodeExporter]

Hi,

Thanks for following up on my issue. See attached file for the gdb backtrace. 

Could I also recommend that you try my output test.yaml file? It seems to me 
that the problem might be the writing rather than the reading, as we get 
different output for max double.

Original comment by lucky13...@gmail.com on 25 Jan 2015 at 7:41

Attachments:

• backtrace.txt

[GoogleCodeExporter]

To clarify my last comment, I am proposing that you remove the write portion of 
the code and use my test.yaml file as input for the reader portion of the code. 
Thanks!

Original comment by lucky13...@gmail.com on 25 Jan 2015 at 7:42

[GoogleCodeExporter]

I tried your output test.yaml file (but my writer's output is actually 
identical to yours). I'm really confused as to what's going on.

If you're willing to continue debugging, it would help to get a small test case 
without yaml-cpp. Specifically, what appears to be happening is that the 
YAML::convert<double>::decode method is returning false for you, for this 
particular input.

So could you copy/paste that method (see yaml-cpp/convert.h - you'll have to 
pull out a macro definition) into a your example, and then replace the line

const std::string& input = node.Scalar();

with setting "input" to be the exact text of the double's string value from 
your file.

This way you should be able to get an example that doesn't use yaml-cpp, but 
still fails for you.

Thanks!

Original comment by jbe...@gmail.com on 25 Jan 2015 at 7:58

[GoogleCodeExporter]

I would be willing to continue debugging, but due to time constraints and an 
upcoming doctoral thesis submission deadline only after August 2015. Thanks!

Original comment by lucky13...@gmail.com on 25 Jan 2015 at 8:13

[GoogleCodeExporter]

No problem - good luck on your thesis!

Original comment by jbe...@gmail.com on 25 Jan 2015 at 8:22

[GoogleCodeExporter]

This issue has moved to github: https://github.com/jbeder/yaml-cpp/issues/229

Original comment by jbe...@gmail.com on 1 Apr 2015 at 3:24

• Changed state: WontFix