More instantiation problems under hpux

[Gabriel Dos Reis]

Loren James Rittle <rittle@latour.rsch.comm.mot.com> writes:

[...]

| Looks OK to me.  However, look at the code at the call site in
| question (note how the evil macro check allows the behavior we see on
| various platforms yet probably allows this to work fine in those
| environments supporting strtof):
| 
| 631     #ifdef _GLIBCPP_USE_C99
| 632           float __f = strtof(__xtrc.c_str(), &__sanity);
| 633     #else
| 634           float __f = static_cast<float>(strtod(__xtrc.c_str(), &__sanity));
| 635     #endif
| 636           if (!(__err & ios_base::failbit)
| 637               && __sanity != __xtrc.c_str() && *__sanity == '\0' && errno == 0)
| 
| I am afraid that it is not correct to check errno == 0 in order to
| declare a non-Inf value in __f since the return value from strtod must
| fit in a double not a float.  The cast to a float might
| truncate/convert to Inf.  That conversion doesn't set errno on
| overflow (according to my understanding and seen behavior).

Kudos to Loren for having clarified the issue!

| Since it is checked for by configure, I don't think the fix is to
| simply use isinf() to check __f.  Also, I'm guessing that people that
| have strtof would prefer this fix inside the #else section, right?
| BTW, for you "all the world is a VAX" fans or anti-fans, from isinf(3)
| on my platform: "Neither the VAX nor the Tahoe floating point have
| distinguished values for either infinity or not-a-number.  These
| routines always return 0 on those architectures."

Thanks a lot for that all.

As an aside, is there a VAX maintainer there?  Can he/she explain that
behaviour, i.e. why can't isinf() detect infinities?

|  Thus, the check
| against overflow might need to be more complex for some architectures
| to get this absolutely portable...
| 
| Sorry I misattributed the behavior I saw on my platform to another
| known issue without looking closer.  Good thing I didn't paper over
| the problem by changing the test case as I proposed to do.  Luckily,
| this appears to be the only place we do this type of thing other than
| in libstdc++-v3/include/c_std/cmath (systems without e.g. sinhf will
| not handle the conversion of the return type of sinh properly for the
| same reason the above code has an issue).

Hmm, that means I really have to reimplement the math libraries where
the C-libary is deficient.  OK.

-- Gaby
CodeSourcery, LLC                       http://www.codesourcery.com