view release on metacpan or  search on metacpan

INSTALL  view on Meta::CPAN

the second one maximal.  The first works in more places than the second.

The C<use64bitint> option does only as much as is required to get
64-bit integers into Perl (this may mean, for example, using "long
longs") while your memory may still be limited to 2 gigabytes (because
your pointers could still be 32-bit).  Note that the name C<64bitint>
does not imply that your C compiler will be using 64-bit C<int>s (it
might, but it doesn't have to).  The C<use64bitint> simply means that
you will be able to have 64 bit-wide scalar values.

The C<use64bitall> option goes all the way by attempting to switch
integers (if it can), longs (and pointers) to being 64-bit.  This may
create an even more binary incompatible Perl than C<-Duse64bitint>: the
resulting executable may not run at all in a 32-bit box, or you may
have to reboot/reconfigure/rebuild your operating system to be 64-bit
aware.

Natively 64-bit systems need neither C<-Duse64bitint> nor C<-Duse64bitall>.
On these systems, it might be the default compilation mode, and there
is currently no guarantee that passing no use64bitall option to the
Configure process will build a 32bit perl. Implementing C<-Duse32bit*>
options is planned for a future release of perl.

=head3 Long doubles

In some systems you may be able to use long doubles to enhance the
range and precision of your double precision floating point numbers
(that is, Perl's numbers).  Use S<C<Configure -Duselongdouble>> to enable
this support (if it is available).

Note that the exact format and range of long doubles varies:
the most common is the x86 80-bit (64 bits of mantissa) format,
but there are others, with different mantissa and exponent ranges.

=head3 "more bits"

You can S<C<Configure -Dusemorebits>> to turn on both the 64-bit support
and the long double support.

=head3 quadmath

One option for more precision is that gcc 4.6 and later have a library
called quadmath, which implements the IEEE 754 quadruple precision
(128-bit, 113 bits of mantissa) floating point numbers.  The library
works at least on x86 and ia64 platforms.  It may be part of your gcc
installation, or you may need to install it separately.

With S<C<Configure -Dusequadmath>> you can try enabling its use, but note
the compiler dependency, you may need to also add "-Dcc=...".
At C level the type is called C<__float128> (note, not "long double"),
but Perl source knows it as NV.  (This is not "long doubles".)

=head3 Taint Support

Traditional perl has provided a security mechanism based on marking
input data as untrusted unless it has been validated by a regex. This
mechanism is called tainting and is enabled with the -T or -t options on
the command line. This support has a performance cost on all code
executed. It is possible to disable this support by providing the
setting C<-Accflags=-DNO_TAINT_SUPPORT> or the setting
C<-Accflags=-DSILENT_NO_TAINT_SUPPORT> to Configure.

The former option C<NO_TAINT_SUPPORT> is more secure and disables taint
support while making the use of the C<-T> or C<-t> options which
normally enable taint support into an untrappable exception to ensure
that no-one uses them while expecting taint checks to run. With this
build mode there can be no confusion if a script supports taint or not.

The latter option, C<SILENT_NO_TAINT_SUPPORT> is less secure but more
flexible in that it silently disables taint support while ignoring the
C<-T> and C<-t> command line options entirely. In this build mode it is
possible to run a script with the C<-T> or C<-t> option and expect taint
support but not get it, so this mode is only recommended to people who
really know what they are doing.

Both modes improve performance although the amount depends on your
workload. It is not unreasonable to expect a 5%-10% improvement in
performance by using one of these options. At this time this build mode
is supported but not recommended, and if you chose to use such a perl
you do so at your own risk. It is possible that there may be
interoperability issues with CPAN distributions as many distributions
are unaware of this build mode and will expect test scripts to pass or
to detect unvalidated data when run under the C<-T> or C<-t>.

=head3 Algorithmic Complexity Attacks on Hashes

Perl 5.18 reworked the measures used to secure its hash function
from algorithmic complexity attacks.  By default it will build with
all of these measures enabled along with support for controlling and
disabling them via environment variables.

You can override various aspects of this feature by defining various
symbols during configure. An example might be:

    sh Configure -Accflags=-DPERL_HASH_FUNC_SIPHASH

B<Unless stated otherwise these options are considered experimental or
insecure and are not recommended for production use.>

Since Perl 5.18 we have included support for multiple hash functions,
although from time to time we change which functions we support,
and which function is default (currently SBOX+SIPHASH13 on 64 bit builds
and SBOX+ZAPHOD32 for 32 bit builds). You can choose a different
algorithm by defining one of the following symbols during configure.
Note that there are security implications regarding which hash function you choose
to use. The functions are listed roughly by how secure they are believed
to be, with the one believed to be most secure at release time being PERL_HASH_FUNC_SIPHASH.

    PERL_HASH_FUNC_SIPHASH
    PERL_HASH_FUNC_SIPHASH13
    PERL_HASH_FUNC_ZAPHOD32

=for apidoc Amnh;||PERL_HASH_FUNC_SIPHASH
=for apidoc_item ||PERL_HASH_FUNC_SIPHASH13
=for apidoc_item ||PERL_HASH_FUNC_ZAPHOD32

In addition, these, (or custom hash functions), may be "fronted" by the
SBOX32 hash function for keys under a chosen size. This hash function is
special in that it has proven theoretical security properties, and is very
fast to hash, but which by nature is restricted to a maximum key length,
and which has rather expensive setup costs (relatively speaking), both in