float stuff again

[Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>]

Hi Dave,

I have reviewed all the followup from my patch to fix
27_io/istream_extractor_arith.cc as portably as I could.

At one point, near the end, you asked:

``After doing a quick hack that didn't work, I looked at this a little
  more deeply.  I see that cmath captures the above if
  _GLIBCPP_USE_C99 is defined.  Then, it undefines the above macros,
  etc.  It does this unconditionally.  Now, _GLIBCPP_USE_C99 isn't
  defined on hpux 11 because it doesn't have the lldiv_t type.  So, we
  just end up with the above being undefined and no way to check the
  attributes of floats without using machine dependent functions or
  macros.  Should configure specifically check for the above?''

No one answered you yet.  This is a ramble, but I will try.

I was going to extend my patch to support isfinite in addition to
isinf, finitef, finite but I see how that wouldn't help your port
either since configure groups all C99 support together.

I think that any machine that has isfinite et al macros and functions,
which adhere to C99, should be made to properly define
_GLIBCPP_USE_C99.  Ignoring the disabled shadow header stuff, I see
that libstdc++-v3/include/c_std/std_cstdlib.h is the only file that
actually requires the lldiv_t type.  Does HPUX 11 claim to otherwise
support C99?  If so, does it declare a prototype for something close
to:

lldiv_t lldiv(long long int numer, long long int denom);

If so, does it just use a different return type than lldiv_t which is
really the same thing.  If so, could it be mapped in
libstdc++-v3/include/c_std/std_cstdlib.h as a special case just so
HPUX 11 looks like it supports C99 like the standard says it should
(it looks like it is very close as is)?

If not, look at how lldiv_t is used.  The requirements of the type are
trivial and could be synthesized for platforms that don't have it:

``7.20.6.2  The div, ldiv, and lldiv functions
[...]
[#3] The div, ldiv, and lldiv functions return  a  structure
       of type div_t, ldiv_t, and lldiv_t, respectively, comprising
       both the quotient and the remainder.  The  structures  shall
       contain  (in  either  order) the members quot (the quotient)
       and rem (the remainder), each of which has the same type  as
       the arguments numer and denom.  If either part of the result
       cannot be represented, the behavior is undefined.''

All this is speculation on how to proceed based on reading C99.  I
don't have access to a port that even attempts to come close.

I guess my position is that my semi-portable non-C99 patch to find a
way to compare against infinite should go in and as a different
effort, systems that are close to being able to use the
_GLIBCPP_USE_C99 code path, should be munged just enough so they can
use it.  It is clear that a port would want to prefer that code path
if at all possible since it is not as kludgy as the non-C99 code
path...

Any chance that you could teach/extend things so HPUX 11 gets
_GLIBCPP_USE_C99 defined?  I would understand if this looks too
convoluted.  As I said, this was a ramble not a fully baked idea.

Regards,
Loren

PS, I do think sorting this out is somewhat orthogonal to Gaby's
reworking of numeric_limits<> support for FP (since HPUX11 isn't
considered a candidate for USE_C99 because of a missing INT type) but
if he feels this is covered by his rework, then I guess this
information/idea can go to him instead. ;-)