More on QUAD_MAX

More on the QUAD_MAX issue:

Configure sets quadkind to 2 (long) and quadtype to "long long".
Combined with the idfef's in perl.h, this causes Perl to set IV_MAX and
IV_MIN to LDBL_MAX and LDBL_MIN because of the #defines in float.h.

I added an ifdef __ia64 to force IV_MAX and IV_MIN to use the bit-inversion
techniques and that seems to work (though the lib/posix.t test inverts the
ok 9 and ok 10).

Then I had an idea to try changing quadkind to 4 (int64_t), quadtype to
"int64_t", and uquadtype to "uint64_t".  Nope.  IV_MAX is now back to being
LDBL_MAX, and I can't figure out why.  The test:

#if defined(USE_64_BIT_INT) && defined(HAS_QUAD)
#  if QUADKIND == QUAD_IS_INT64_T && defined(INT64_MAX)

isn't succeeding.  By visual inspection, all of the these are true EXCEPT
for the defined(INT64_MAX), which is set in <inttypes.h> and included by
handy.h by:

#ifdef PERL_CORE
#   ifdef HAS_QUAD
#       if QUADKIND == QUAD_IS_INT64_T
#           include <sys/types.h>
#           ifdef I_INTTYPES /* e.g. Linux has int64_t without <inttypes.h> */
#               include <inttypes.h>
#           endif
#       endif

and I_INTTYPES is set.

Another strangeness that may or may not be related is in the POSIX extension,
I get errors about LDBL_MIN and _MAX not being found.  Yet this is in the
same compile that these are definitely set, since the QUAD_MIN and _MAX macros
are being set to equal LDBL_MIN and _MAX!

Oh, wait, I figured this one out.  When POSIX.c is compiled, -DPERL_CORE isn't
being set!  Is this a bug?


Jeff

• More on QUAD_MAX by Jeff Okamoto
• Re: More on QUAD_MAX by Peter Prymmer
• Re: More on QUAD_MAX by Jarkko Hietaniemi
• Re: More on QUAD_MAX by Jeff Okamoto
• Re: More on QUAD_MAX by Nick Ing-Simmons
• Re: More on QUAD_MAX by Jeff Okamoto
• Re: More on QUAD_MAX by Nick Ing-Simmons