------- Comment #4 from pcarlini at suse dot de 2007-12-10 21:01 ------- (In reply to comment #3) > Ok, thanks for the information. So the mystery > is then: why is failbit set on that read in 4.2.2 > and not 4.0.1 (and whatever version of libstdc++ > each is linking against). Inserting a little check and error message > code does confirm that > 1) On 4.2.2, failbit is set after the read, and clearing it > does make the next read work correctly. But the > first read does fail, and results in the wrong value. > 2) On 4.0.1, failbit is _not_ set after the read, and the > whole thing works the way it should. > > After all, 1e-321 is not too small for a 64 bit double, > so the read should work and there should be no underflow.
Note that, *assuming* this is really the case, then the problem cannot be with the C++ library, because we simply forward to the underlying C library as regards diagnosing underflow. In any case, I can confirm that, as I expected, on powerpc-darwin8.11 the behavior of 4.0.x and 4.2.x vs underflow is the same: when underflow happens, failbit is set. Again, as I expected, 4.3.0 behaves differently, never sets eofbit on underflow. I still think that something outside or (GCC / libstdc++-v3) control is happening on i686-darwin wrt underflow, because there are no differences in our code between 4.0.x and 4.2.x that can explain the difference. Unless someone diagnoses in detail what is going wrong on i686-darwin (which I don't have available), the problem will not be dealt with in 4.2.x, I'm afraid, doesn't appear as a regression and the changes in 4.3.0 are too invasive for 4.2.3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34423
