EDN Admin
Well-known member
Hi,
Im a first time poster, so I hope Im in the right sub-forum and everything. Im working on upgrading a C++ application from Visual Studio 2010 to 2012 (Update 1), and Im running into a problem with the simple task of reading a double from an std::istream. It has no problem with "nice" floating point values such as
30.9446944444444440
(this happens to be a latitude). But the file also contains several instances of the following number, which is not handled gracefully.
179769313486231610000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000.0000000000000000
(Thats 1.797....e+308, the prototypical double garbage value.) This number was written out by the same application at some earlier time, and perhaps it should have stored this value differently, but no matter; thats the way its stored now, and there was no problem reading it in VC10.
In VC11, however...After trying to read this number, the std::istream is left in an error state (2, or "failbit"), and further input operations fail, resulting in a downstream crash.
Ive stepped into the library code that parses floats (always a fun activity), and as far as I can tell, something goes wrong in the method _Stodx, located in xxstod.h. This method is converting a "stringy" floating point into an actual number type. The stringy value it gets is
"179769313486231610000000000000000000."
But when it gets to the bottom of the function, the value its returning is
1.#INF000000000000
and the error code "perr" is now non-zero. I started to step into line 45 of xxstod.h, but I figured, three calls deep into standard library code, I might be better off asking the experts.
Why does VC11 fail to gracefully read in these numbers? Was I just lucking out in VC10? In the end, Im not that concerned about the actual value (since in this boundary case, its garbage anyway and the application will ignore it), but I need to be able to continue reliably reading the remainder of the file.
Any help would be appreciated.
Thanks,
Reid
View the full article
Im a first time poster, so I hope Im in the right sub-forum and everything. Im working on upgrading a C++ application from Visual Studio 2010 to 2012 (Update 1), and Im running into a problem with the simple task of reading a double from an std::istream. It has no problem with "nice" floating point values such as
30.9446944444444440
(this happens to be a latitude). But the file also contains several instances of the following number, which is not handled gracefully.
179769313486231610000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000.0000000000000000
(Thats 1.797....e+308, the prototypical double garbage value.) This number was written out by the same application at some earlier time, and perhaps it should have stored this value differently, but no matter; thats the way its stored now, and there was no problem reading it in VC10.
In VC11, however...After trying to read this number, the std::istream is left in an error state (2, or "failbit"), and further input operations fail, resulting in a downstream crash.
Ive stepped into the library code that parses floats (always a fun activity), and as far as I can tell, something goes wrong in the method _Stodx, located in xxstod.h. This method is converting a "stringy" floating point into an actual number type. The stringy value it gets is
"179769313486231610000000000000000000."
But when it gets to the bottom of the function, the value its returning is
1.#INF000000000000
and the error code "perr" is now non-zero. I started to step into line 45 of xxstod.h, but I figured, three calls deep into standard library code, I might be better off asking the experts.
Why does VC11 fail to gracefully read in these numbers? Was I just lucking out in VC10? In the end, Im not that concerned about the actual value (since in this boundary case, its garbage anyway and the application will ignore it), but I need to be able to continue reliably reading the remainder of the file.
Any help would be appreciated.
Thanks,
Reid
View the full article