| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
The better to be able to navigate around the file when debugging.
|
|
|
|
|
|
|
| |
Two instances of glob() which run on MSWin32 were overlooked in commit
df8b709bfcaea9932dd434f18393bfcb4e3d5568.
Thanks to Christian Walde for Win32 smoke testing and assistance in diagnosis.
|
|
|
|
| |
For: RT # 133586
|
|
|
|
|
|
|
| |
For: RT # 133499
Per Tony Cook, the behavior changed in
e1a7ec8d453649a65aea34af90c3042a5137191e (March 2013).
|
| |
|
|
|
|
| |
This removes arybase and all its surrounding machinery.
|
|
|
|
|
|
|
|
|
|
| |
It continues to exist as a CPAN distribution.
Increment $B::Terse::VERSION and $B::Concise::VERSION due to changes in POD.
Remove internal links to B::Debug within two .pod files.
For: RT #130410
|
|
|
|
|
|
|
|
|
|
|
|
| |
With -Dquadmath C++ builds, the calls to log10() and ldexp() would
cause ambiguous overloaded function errors, since all of log10(float),
log10(double) and log10(long double) were canidates for a
log10(__float128) call. Similarly for ldexp().
signbit() had a different problem, two of the tests in ext/POSIX/t/math.t
failed with the default signbit() macro, presumably because the
__float128 was being converted to a long double, since the macro in
math.h didn't special case for __float128.
|
| |
|
| |
|
|
|
|
|
|
| |
This reverts commit e6e9f5a198d7e054e6857a9c6e99a07d639f7f3c.
I think it best to revert this until I'm ready for stating in perldelta
exactly the options for replacing uses of these functions.
|
|
|
|
|
|
| |
These test all combinations of bytes at all likely to have any issues.
They are run only when an environment variable is set to a particular
obscure value, as they take a long time.
|
|
|
|
|
| |
These have been deprecated since 5.18, and have security issues, as they
can try to read beyond the end of the buffer.
|
|
|
|
|
|
|
|
|
|
| |
This changes the internal function grok_atoUV() to not require its input
to be NUL-terminated. That means the existing calls to it must be
changed to set the ending position before calling it, as some did
already.
This function is recommended to use in a couple of pods, but it wasn't
documented in perlintern. This commit does that as well.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Trying a USE_CPLUSPLUS=define build with dmake (USE_CPLUSPLUS not
implemented in GNUMakefile) causes the following error
---------
gcc -c -xc++ -I.\include -I. -I.. -DWIN32 -DPERLDLL -DPERL_CORE -s -O2 -fwrapv -
fno-strict-aliasing -DPERL_EXTERNAL_GLOB -DPERL_IS_MINIPERL -omini\globals.o ..
\globals.c
In file included from ..\globals.c:32:0:
..\perl.h:6754:50: error: too many initializers for 'U8 [8] {aka unsigned char [
8]}'
INFNAN_U8_NV_DECL PL_inf = { { LONGDBLINFBYTES } };
^
..\perl.h:6790:50: error: too many initializers for 'U8 [8] {aka unsigned char [
8]}'
INFNAN_U8_NV_DECL PL_nan = { { LONGDBLNANBYTES } };
^
dmake: Error code 129, while making 'mini\globals.o'
---------
in plain C mode builds, this error was just a warning and nobody paid
attention to it for a while
---------
gcc -c -I.\include -I. -I.. -DWIN32 -DPERLDLL -DPERL_CORE -s -O2 -fwrapv -fno-s
trict-aliasing -DPERL_EXTERNAL_GLOB -DPERL_IS_MINIPERL -omini\globals.o ..\glob
als.c
In file included from ..\globals.c:32:0:
..\perl.h:5432:42: warning: excess elements in array initializer
#define INFNAN_U8_NV_DECL EXTCONST union { U8 u8[NVSIZE]; NV nv; }
^
..\perl.h:6754:1: note: in expansion of macro 'INFNAN_U8_NV_DECL'
INFNAN_U8_NV_DECL PL_inf = { { LONGDBLINFBYTES } };
^
..\perl.h:5432:42: warning: (near initialization for 'PL_inf.u8')
#define INFNAN_U8_NV_DECL EXTCONST union { U8 u8[NVSIZE]; NV nv; }
^
..\perl.h:6754:1: note: in expansion of macro 'INFNAN_U8_NV_DECL'
INFNAN_U8_NV_DECL PL_inf = { { LONGDBLINFBYTES } };
^
..\perl.h:5432:42: warning: excess elements in array initializer
#define INFNAN_U8_NV_DECL EXTCONST union { U8 u8[NVSIZE]; NV nv; }
^
-------------
Now on VC C++ build, LONGDBLINFBYTES is 8 bytes, as defined in
LONGDBLINFBYTES macro in config_H.vc, and for VC, "long double" is always
typedefed by the CC to "double", so there was no warning, but on GCC,
"long double" is the 80 bit/10 byte type and in config_H.gc the 12 byte
version of INF is inside LONGDBLINFBYTES macro. Because LONG_DOUBLESIZE
define was previously "8" because of makefile logic regardless of CC,
# elif NVSIZE == LONG_DOUBLESIZE && defined(LONGDBLINFBYTES)
INFNAN_U8_NV_DECL PL_inf = { { LONGDBLINFBYTES } };
was being hit on GCC, even though NVSIZE is 8 as it should be, but
LONGDBLINFBYTES was 12. Hence the warning. I didnt research why this
warning on GCC didn't cause test failures. Perhaps full perl recomputes
the correct initializer in config_sh.PL and doesn't rely on what was in the
miniperl initializer for PL_inf.
To fix things, always emit the correct value for LONG_DOUBLESIZE and dont
hardcode it at 8 for miniperl. 8 must stay for all VCs, and 12/16 is for
GCC. Although GNUMakefile doesn't support a USE_CPLUSPLUS build option,
it has provisons to support it one day. To keep things in sync, copy
miniperl config.h append changes from makefile.mk to GNUMakefile. Also
collapse 2 shell cmd lines in "ifeq ($(USE_LONG_DOUBLE),define)" to reduce
number of proc launches of cmd.exe by the maketool (perf issue).
Next C++ build issue.
APItest.xs: In function 'void XS_XS__APItest__Backrefs_Comctl32Version(Perl
Interpreter*, CV*)':
APItest.xs:6806:37: error: cast from 'LPSTR {aka char*}' to 'WORD {aka shor
t unsigned int}' loses precision [-fpermissive]
MAKEINTRESOURCE(VS_FILE_INFO));
^
dmake: Error code 129, while making 'APItest.o'
VS_FILE_INFO is internally "RT_VERSION" which is MAKEINTRESOURCE(16). The
output type of MAKEINTRESOURCE is a char *. GCC complains about casting
that char * back down to a WORD (aka short). Put in a size_t used for
pointer arithimitic to silence the error. Another option is to
remove the outer MAKEINTRESOURCE in APItest.xs since RT_VERSION has
MAKEINTRESOURCE internally, but that assumes implementation details of
headers so pick the less dependency on header design option.
|
|
|
|
|
|
| |
S_gv_fetchmeth_internal supports its arguments being either an SV or
a (name, len) pair. But when performing an ISA traversal to get method from
a parent class, it accounted only for the latter.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
really old Mingw GCCs (3.4.5 specifically) dont implement _alloca
correctly, switch to a simpler variation
a follow on to perl #133084 and see also problems I had with alloca on
very old GCCs in https://rt.cpan.org/Public/Bug/Display.html?id=80217
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In an XS file,
# If ...
is being interpreted by at least one compiler / build system as a
CPP macro rather than as an XS code comment.
Indent it to remove ambiguity.
http://nntp.perl.org/group/perl.perl5.porters/250229
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Commit bb6a367ad5d replaced an XPUSHs inside a loop with an EXTEND
outside it, but didn't move the dSP to match. Even if it did, that
would have been wrong, since the loop might push more than one value.
Revert that bit of the commit.
In passing, move the declaration of dl_librefs and dl_libref into the
scope where they're used.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The names of the months and weekdays are swapped with the abbreviated
names before netbsd 7, so skip the tests on those platforms. See their
commit:
revision 1.12.2.1
date: 2013-09-07 20:11:41 +0400; author: bouyer; state: Exp; lines:
+38 -38; commitid: HURUJwL5bnZmww4x;
Apply patch, requested by joerg in ticket #934:
lib/libc/locale/global_locale.c: patch
provide consistent and correct data for the C locale.
|
|
|
|
|
| |
When dumping a subtree, display the op_parent() value for
the top-most node of the subtree.
|
|
|
|
|
|
|
| |
Includes:
- C89 changes from Aaron Crane
- Unit test timing fixes
- Don't use loop: as a label to avoid struct loop confusion
|
|
|
|
|
| |
See thread beginning at
http://nntp.perl.org/group/perl.perl5.porters/244215
|
|
|
|
|
|
|
|
|
| |
Prior to this patch, the code assumed that if you have the other, more
significant, POSIX 2008 functions available, that duplocale was present
and correctly functioning too.
However, we found that there have been bugs in it, so that a hints file
or Configure probe might want to exclude just it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Prior to Visual Studio 2015, the localeconv() function only looks at the
global locale, not the per-thread one it should. This works around this
by creating critical sections, switching to the global locale to call
localeconv(), then switching back. For the most common usage, it avoids
the switch by parsing a string it generates that should contain the
desired substring. This leaves the switch required for retrieving the
floating point grouping separator and the currency string, plus
POSIX::localeconv(). The first two could be avoided by extra code as
detailed in the pod for switch_to_global_locale(); patches welcome!
|
|
|
|
|
|
|
| |
This applies to I18N::Langinfo, and the API function Perl_langinfo.
Windows doesn't have nl_langinfo, so an emulation is used. It turns out
that it is easy to emulate the behavior for the CODESET item on Windows,
as that vendor has kept things consistent.
|
|
|
|
|
|
|
| |
This commit will turn UTF-8 on in the returned SV if its string is legal
UTF-8 containing something besides ASCII, and the locale is a UTF-8 one.
It is based on the patch included in the ticket, but is generalized to
handle edge cases.
|
|
|
|
| |
Removing trailing space; fix typo, clarify
|
|
|
|
|
|
|
|
|
|
|
|
| |
I thought I had done this earlier, but testing on Windows demonstrated
that I hadn't.
While at it, move the details in the docs for Perl_langinfo to the
module's pod.
This doesn't follow the paradigm for putting the Configure stuff in all
the related configure files, but I saw no point to doing so. If you are
reading this because I was wrong, feel free to ticket it or fix it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Earlier in the 5.27 series, I introduced Perl_langinfo which calls
the system nl_langinfo() on platforms that have it, and emulates it
otherwise. For each enum parameter 'foo', I made an equivalent
parameter PERL_foo. I did this so that no conflicts would arise if
any 'foo' were negative. This is less than ideal to have to rename the
parameters.
In looking further, I realized that perl has always excluded the
possibility of negative values for 'foo', so my precaution is
unnecessary. And before this new code is released is the time to fix up
the interface.
|
| |
|
|
|
|
| |
These now appear in the file in their logical order
|
|
|
|
|
|
|
|
|
| |
Using loop as a label conflicts with Perl's "struct loop" and "LOOP" types
and Visual C 2003 in C++ mode (but not the default C build) doesn't like
that. The loop label is from 5.27.1 commit 0db967b2e6
"[perl #131211] fixup File::Glob degenerate matching"
bsd_glob.c(995) : error C2226: syntax error : unexpected type 'loop'
|
|
|
|
|
| |
These were made using the old version number, and the error was not
caught, because of the lateness in getting 5.27.9 tagged
|
|
|
|
|
|
| |
Daniel Dragan pointed out that this parameter is unused (the commits
that want it didn't get into 5.28), and is causing a table to be
duplicated all over the place, so just remove it for now.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This test file occasionally fails test numbers 1 and/or 2 on smokes.
These two tests measure how long it takes to do a matching and
non-matching glob() with a lot of "a*a*a*...." and fail if the
match and non-matching times differ too much (the original bug was that
non-match went exponential on number of "a*"'s).
However, on good systems, the timings returned are typically
sub-millisecond, so I'm guessing the occasional failures are due to
(small measured noise) * 100 > (another small measured noise).
So this commit avoids tests 1&2 failing unless the values measured
are large enough not to be merely noise.
This is just speculation on my part though - I couldn't reproduce a
failure myself.
|
|
|
|
| |
This detail can help in interpreting the results.
|
|
|
|
|
|
|
|
|
| |
The value returned for ALT_DIGITS may vary by locale and platform.
Change the test to only look for a result, as opposed to a particular
result.
This should fix https://rt.perl.org/Ticket/Display.html?id=132879
but I'll leave the ticket open until that is verified.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes #132729 in the particular instance where an XSUB is
called via ampersand syntax when @_ has ‘holes’, or nonexistent ele-
ments, as in:
@_ = ();
$_[1] = 1;
&xsub;
This means that if the XSUB or something it calls unshifts @_, the
first argument passed to the XSUB will now refer to $_[1], not $_[0];
i.e., as of this commit it is correctly shifted over. Previously, a
‘defelem’ was used, which is a magical scalar that remembers its index
in the array, independent of whether the array was shifted.
In addition, the old code failed to mortalize the defelem, so this
commit fixes a memory leak with the new ‘non-elem’ mechanism (a spe-
cially-marked element stored in the array itself).
|
|
|
|
|
|
| |
This (large) commit allows locales to be used in threaded perls on
platforms that support it. This includes recent Windows and Posix 2008
ones.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
khw could not find any modules on CPAN that correctly use the C library
function setlocale(). (The very few that do try, do not use it
correctly, looking at the return value incorrectly, so they are broken.)
This analysis does not include modules that call non-Perl libaries that
may call setlocale().
And, a future commit will render the setlocale() function useless in
some configurations on some platforms.
So this commit adds Perl_setlocale(), for XS code to call, and which is
always effective, but it should not be used to alter the locale except
on platforms where the predefined variable ${^SAFE_LOCALES} evaluates to
1.
This function is also what POSIX::setlocale() calls to do the real work.
|
|
|
|
|
|
|
| |
Commit 7d5966ae3c3b8f0e43fa09554a46cb8de9c98f5f added use of
localeconv_l(). But this commit is buggy in some locales. It needs to
find the current locale AFTER any changes have been made due to the
LC_NUMERIC locale toggling.
|
|
|
|
|
| |
This missiing typemap has slowed me down on numerous occasions, as I
keep forgetting it's missing
|