Front page | perl.perl5.porters |
Postings from September 2013
On Fri, Sep 13, 2013 at 03:47:44PM +0100, Aaron Crane wrote:
> Nicholas Clark <perlbug-followup@perl.org> wrote:
> > I'm not sure that it's worth actually doing this part:
> >
> > commit 81775faa427fb3dcb687559381d9a5cb616d20b3
> > Author: Nicholas Clark <nick@ccl4.org>
> > Date: Wed Sep 11 12:20:05 2013 +0100
> >
> > Don't undefine HAS_QUAD with 32 bit IVs on a platform with a 64 bit type.
> >
> > When commit de1c2614758a00c0 added support for $Config{d_quad} and HAS_QUAD
> > in Oct 1999, it also undefined HAS_QUAD. The presence of a 64 bit type
> > doesn't directly affect the choice of using 32 or 64 bit types for IVs, so
> > undefining this simply throws away information which might be of use to C
> > and XS code.
>
> I agree that it's not worth it; HAS_QUAD's documentation has differed
> from its behaviour for long enough that changing the latter seems
> likely to break more than it fixes.
I've dropped that commit and merged the rest back to blead.
However, I think we're going to need to have HAS_QUAD defined with PERL_CORE,
because we need the proper 64 bit handling for integer constants on (at
least) HP-UX. Without the ULL suffix the compiler there is truncating two of
the constants used by the new drand48 code to 32 bits, which is breaking
things badly.
I'm about to push a smoke-me branch for that (once I've tested it on VMS)
But this ticket is, I believe, resolved.
> There may be a case for adding a HAS_QUAD_AVAILABLE preprocessor
> symbol with the same behaviour as HAS_QUAD's documentation. But, as
> you point out, CPAN authors seem to have converged on just using long
> long, which works in most places. And the hypothetical new symbol
> would only be available in 5.20+ (such things don't go into ppport.h,
> right?), so its utility would seem to be low.
Yes, that doesn't really seem worth it.
Nicholas Clark
Thread Previous