| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This way we can call it twice: first to count the size of output (and
sanity check the extraction indices), and the second time to actually
extract. Otherwise with bad extraction code we will smash the stack.
Furthermore, this makes for cleaner code since the large #ifdef forest
(about differing long double formats, and different uv/nv/quad sizes)
is moved within the helper function.
Furthermore: IEEE 754 128-bit extraction was extracting wrong:
we need only the mantissa bits, and in the right nybble order.
Last but not least, handle the 'implicit bit' of IEEE 754 quadruple
and double-double (but which is explicitly *not* in the 80-bit format).
(If we handled the standard 64-bit format by explicit byte extraction,
instead of frexp+ldexp the hidden bit would be needed there, too.)
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
Do not use system strtod/strtold since its C99 (which we do not require).
If we can fit the mantissa bits of a NV to a UV (which is the case for
the most common format, 64-bit IEEE 754 double, which has 52 mantissa bits)
we will use that, and only in the end convert to NV. If we cannot fit
the bits, accumulate the bits incrementally to a NV.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Do not use the system sprintf since %a/%A is C99 (which we do not
require), and even if we did, there is room for interpretation
(for example whether to print trailing zeros or not) which means
that existing implementations will inevitably differ.
For the most common case, 64-bit doubles of IEEE 754, use first
frexp to extract the exponent, and then ldexp to scale the result
to a 64-bit unsigned integer.
For long doubles (80-bit or 128-bit) we look directly at the mantissa
(also known as fraction, or significand) bytes, and their 4-bit nybbles,
and extract them in correct order.
Since we bypass system printf, we need to do our own aligning, filling,
rounding, and other printf logic.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The default for populating %ENV on VMS is from logical names
first and the CRTL environ array second unless overridden by
setting PERL_ENV_TABLES. That's a reasonable default for DCL,
but not quite right when running under bash as exports under bash
might end up hidden behind logical names. So reverse the default
order when GNV$UNIX_SHELL is set.
Also stop mentioning that setenv() may not be present in the CRTL
since it is present for VMS versions 7.0 and later and those are
the only ones we support.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
in Perl 5.14 the following segfaults:
*CORE::GLOBAL::require = sub { }; eval "require";
in Perl 5.18
perl -wle'eval "require";'
produces a spurious warning:
Use of uninitialized value $_ in require at (eval 1) line 1.
In other perls:
perl -e 'eval q/require $this/ or print $@'
produces:
Null filename used at (eval 1) line 1.
The error message is crappy, totally unfit for a perl audience,
and the spurious warning is just confusing. There is no $_ in use
here, why do we warn about it.
It looks like 9e3fb20c fixed the segfault (by accident), and also
somehow meant that the "Null filename" error would not ever be
produced.
So this patch ditches the crappy error and replaces it with something
meaningful and informative, and tests that we do not regress and start
segfaulting again.
|
| |
|
| |
|
|
|
|
| |
Some deprecations have become fatal in v5.20
|
| |
|
|
|
|
|
| |
The warning message is no longer misleading, so no need to point out
anything about it.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
It's been deprecated since v5.12.
|
|
|
|
|
| |
'either' refers only to one of two possibilities. Since this
has more than that, 'either' is grammatically incorrect.
|
| |
|
|\
| |
| |
| |
| | |
Conflicts:
t/porting/libperl.t
|
| | |
|
| | |
|
| | |
|
|/ |
|
|
|
|
| |
Not included the parts that are automated (module changes and acknowledgements).
|
| |
|
| |
|
|
|
|
|
| |
Changes like 31114fe991, which has just been cherry-picked into maint-5.20,
should be allowed.
|
|
|
|
|
|
|
|
| |
this will slightly speed up perl's build time by not loading XSLoader.pm
and DynaLoader.pm into the process, and then die()+eval trap when trying
to load the XS module.
Tony: update perldelta message to avoid a broken link
|
|
|
|
|
| |
(perldelta: Say we're upgrading from 0.29 since we've already upgraded from
that since 5.21.0.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add the boolean field op_lastsib to OPs. Within the core, this is set
on the last op in an op_sibling chain (so it is synonymous with op_sibling
being null). By default, its value is set but not used.
In addition, add a new build define (not yet enabled by default),
-DPERL_OP_PARENT, that forces the core to use op_lastsib to detect the
last op in a sibling chain, rather than op_sibling being NULL. This frees
up the last op_sibling pointer in the chain, which rather than being set
to NULL, is now set to point back to the parent of the sibling chain (if
any).
This commit also adds a C-level op_parent() function and B parent()
method; under default builds they just return NULL, under PERL_OP_PARENT
they return the parent of the current op.
Collectively this provides a facility not previously available from B:: nor
C, of being able to follow an op tree up as well as down.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
This character class matches a single byte within a multi-byte utf8 char,
and so breaks encapsulation. It is buggy, and can corrupt utf8 strings.
This deprecation was agreed in the thread starting
http://nntp.perl.org/group/perl.perl5.porters/210621
|
| |
|
|
|
|
|
|
| |
The original version of this patch, introduced in
v5.19.2-389-g8140a7a, warned confusingly when incrementing strings
like "123abc". This version includes the fix patch from [perl
|
| |
|
| |
|
|
|
|
|
|
|
| |
The build process creates a symlink pod/perl$platform.pod pointing to
README.$platform for each relevant platform, and we therefore want Git to
ignore those generated symlinks. Where we no longer support a given
platform, there's no need to have a gitignore entry for it.
|