| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Coverity CID 104782 (only flagged the deb.c spot)
|
|
|
|
|
|
|
|
|
| |
I recently added a new context stack type, MULTICALL. The table
si_names[], which contains the stack type names to display with
-Dsv a new label added, "MULTICALL", but the previous label didn't
have a comma after it, so the two labels were actually being concatenated.
Spotted by Coverity
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently when MULTICALL pushes a new stackinfo, it uses the si_type
PERLSI_SORT. This is probably just a hangover from when the MULTICALL code
was created from similar code used to implement sort.
Change it to use the new PERLSI_MULTICALL si_type.
The si_type value is mainly used for debugging/dumping purposes,
apart from a few places where we check for whether this is
the top stack (PERLSI_MAIN); or check for a sort BLOCK (cxix = 0,
CXt_NULL, PERLSI_SORT).
So this commit should have no immediate effect. It will in future
however allow us to detect whether we have a sort or a true MULTICALL.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
An empty cpan/.dir-locals.el stops Emacs using the core defaults for
code imported from CPAN.
Committer's work:
To keep t/porting/cmp_version.t and t/porting/utils.t happy, $VERSION needed
to be incremented in many files, including throughout dist/PathTools.
perldelta entry for module updates.
Add two Emacs control files to MANIFEST; re-sort MANIFEST.
For: RT #124119.
|
| |
|
|
|
|
|
|
|
|
| |
You need to configure with g++ *and* -Accflags=-DPERL_GLOBAL_STRUCT
or -Accflags=-DPERL_GLOBAL_STRUCT_PRIVATE to see any difference.
(g++ does not do the "post-annotation" form of "unused".)
The version code has some of these issues, reported upstream.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For S_ functions, remove the context.
For Perl_ functions, add PERL_UNUSED_CONTEXT.
Tricky because sometimes depends on DEBUGGING, and sometimes
on whether we are have PERL_IMPLICIT_SYS.
(Why all the mathoms Perl_is_uni_... and Perl_is_utf8_...
functions are not being whined about is a mystery.)
vutil.c (included via util.c) has one of these, but it's cpan/,
and a known problem: https://rt.cpan.org/Ticket/Display.html?id=96100
|
|
|
|
| |
Fix for Coverity perl5 CID 45359.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This removes most register declarations in C code (and accompanying
documentation) in the Perl core. Retained are those in the ext
directory, Configure, and those that are associated with assembly
language.
See:
http://stackoverflow.com/questions/314994/whats-a-good-example-of-register-variable-usage-in-c
which says, in part:
There is no good example of register usage when using modern compilers
(read: last 10+ years) because it almost never does any good and can do
some bad. When you use register, you are telling the compiler "I know
how to optimize my code better than you do" which is almost never the
case. One of three things can happen when you use register:
The compiler ignores it, this is most likely. In this case the only
harm is that you cannot take the address of the variable in the
code.
The compiler honors your request and as a result the code runs slower.
The compiler honors your request and the code runs faster, this is the least likely scenario.
Even if one compiler produces better code when you use register, there
is no reason to believe another will do the same. If you have some
critical code that the compiler is not optimizing well enough your best
bet is probably to use assembler for that part anyway but of course do
the appropriate profiling to verify the generated code is really a
problem first.
|
|
|
|
|
| |
This updates the editor hints in our files for Emacs and vim to request
that tabs be inserted as spaces.
|
|
|
|
|
|
| |
Message-ID: <25940.1225611819@chthon>
Date: Sun, 02 Nov 2008 01:43:39 -0600
p4raw-id: //depot/perl@34698
|
|
|
| |
p4raw-id: //depot/perl@34585
|
|
|
|
|
|
|
|
|
|
|
|
| |
ability to create landmines that will explode under someone in the
future when they upgrade their compiler to one with better
optimisation. We've already done this at least twice.
(Yes, some of the assertions are after code that would already have
SEGVd because it already deferences a pointer, but they are put in
to make it easier to automate checking that each and every case is
covered.)
Add a tool, checkARGS_ASSERT.pl, to check that every case is covered.
p4raw-id: //depot/perl@33291
|
|
|
|
|
| |
This simplifies some code in Perl_deb_stack_all().
p4raw-id: //depot/perl@33016
|
|
|
| |
p4raw-id: //depot/perl@32237
|
|
|
|
|
| |
Message-ID: <46D617B5.3000002@iki.fi>
p4raw-id: //depot/perl@31765
|
|
|
|
|
|
| |
(Might be nice to display the thread ID too under ithreads, but I can't
see a clean way to get that)
p4raw-id: //depot/perl@29960
|
|
|
|
|
| |
Message-ID: <44D7AA6B.4040802@iki.fi>
p4raw-id: //depot/perl@28674
|
|
|
|
|
| |
Message-ID: <44D2E203.5050201@iki.fi>
p4raw-id: //depot/perl@28662
|
|
|
|
|
| |
Message-ID: <20060424232038.7550f9b6@r2d2>
p4raw-id: //depot/perl@27962
|
|
|
|
|
| |
Message-ID: <20060221062711.GA16160@petdance.com>
p4raw-id: //depot/perl@27300
|
|
|
| |
p4raw-id: //depot/perl@27238
|
|
|
|
|
| |
Message-ID: <20060209154018.GA14610@petdance.com>
p4raw-id: //depot/perl@27136
|
|
|
|
|
| |
did not update)
p4raw-id: //depot/perl@26732
|
|
|
|
|
| |
Message-ID: <43BE7C4D.1010302@gmail.com>
p4raw-id: //depot/perl@26675
|
|
|
|
|
| |
Message-ID: <20051205194613.GB7791@petdance.com>
p4raw-id: //depot/perl@26281
|
|
|
| |
p4raw-id: //depot/perl@26175
|
|
|
|
|
| |
Message-ID: <20051104211256.GA12651@petdance.com>
p4raw-id: //depot/perl@26028
|
|
|
|
|
| |
Message-ID: <20050703233156.GA20967@petdance.com>
p4raw-id: //depot/perl@25067
|
|
|
|
|
|
| |
in read-only mode. Make vi modelines compatible with non-vim
vi versions.
p4raw-id: //depot/perl@24445
|
|
|
|
|
| |
(except the generated ones)
p4raw-id: //depot/perl@24440
|
|
|
| |
p4raw-id: //depot/perl@24106
|
|
|
|
|
| |
Message-Id: <2f14220e7101a03f7659dbe79a03b115@petdance.com>
p4raw-id: //depot/perl@24074
|
|
|
|
|
| |
Message-ID: <20050319072830.GA7721@petdance.com>
p4raw-id: //depot/perl@24049
|
|
|
| |
p4raw-id: //depot/perl@23180
|
|
|
| |
p4raw-id: //depot/perl@23176
|
|
|
|
|
| |
structure directly instead
p4raw-id: //depot/perl@23156
|
|
|
|
|
|
|
| |
(Lots of Perl 5 source code archaeology was involved.)
Larry didn't make strangled noises when I showed him
the patch, either :-)
p4raw-id: //depot/perl@19242
|
|
|
| |
p4raw-id: //depot/perl@18807
|
|
|
| |
p4raw-id: //depot/perl@18801
|
|
|
|
|
| |
Still imcomplete. Configure will follow
p4raw-id: //depot/perl@18030
|
|
|
|
|
|
| |
Subject: [PATCH deb.c] Re: HiRes failure is success?
Message-ID: <20020904161115.E27603@fdgroup.com>
p4raw-id: //depot/perl@17843
|
|
|
|
|
| |
p4raw-link: @17718 on //depot/perl: d672126634c5e568812ed35d4c8ea53a9a55ee4c
p4raw-id: //depot/perl@17842
|
|
|
|
|
| |
Message-id: <20020805005533.B26111@fdgroup.com>
p4raw-id: //depot/perl@17718
|
|
|
|
|
|
| |
Message-Id: <20020302054958.A5511@math.ohio-state.edu>
p4raw-link: @14577 on //depot/perl: 0ad5258ff3f3328f321188cbb4fcd6a74b365431
p4raw-id: //depot/perl@14956
|
|
|
|
|
| |
Message-ID: <pudge-10FC3D.16314108022002@onion.valueclick.com>
p4raw-id: //depot/perl@14608
|
|
|
| |
p4raw-id: //depot/perl@14391
|
|
|
|
|
|
| |
Thanks to H. Merijn Brand for the patch.
Some of the comments and or guards might be removable in perl.h now.
p4raw-id: //depot/perl@11758
|
|
|
| |
p4raw-id: //depot/perl@8289
|
|
|
| |
p4raw-id: //depot/perl@7984
|