| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
New macros {GCC,CLANG}_DIAG_{IGNORE,RESTORE}_{DECL,STMT}, which take a
following semicolon. It is necessary to use the _DECL or _STMT version
as appropriate to the context. Fixes [perl #130726].
|
| |
|
|
|
|
|
|
| |
Some vars have been tagged as const because they do not change in their
new scopes. In pp_reverse in pp.c, I32 tmp is only used to hold a char,
so is changed to char.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
C++11 requires space between the end of a string literal and a macro, so
that a feature can unambiguously be added to the language. Starting in
g++ 6.2, the compiler emits a warning when there isn't a space
(presumably so that future versions can support C++11). Unfortunately
there are many such instances in the perl core. This commit fixes
those, including those in ext/, but individual commits will be used for
the other modules, those in dist/ and cpan/.
This commit also inserts space at the end of a macro before a string
literal, even though that is not deprecated, and removes useless ""
literals following a macro (instead of inserting a blank). The result
is easier to read, making the macro stand out, and be clearer as to the
intention.
Code and modules included with the Perl core need to be compilable using
C++. This is so that perl can be embedded in C++ programs. (Actually,
only the hdr files need to be so compilable, but it would be hard to
test that just the hdrs are compilable.) So we need to accommodate
changes to the C++ language.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
| |
HP-UX B.11.31/64 gcc 4.7.2 with -DDEBUGGING:
taint.c:38:2: warning: format '%ld' expects argument of type 'long int', but argument 5 has type 'uid_t' [-Wformat]
This removes the sole use of Uid_t_f (and there are none of Gid_t_f)
from the core.
|
|
|
|
|
|
|
|
| |
My recent commit 5d37acd6b65eb enabled (among other things)
format-arg checking of taint_proper(). This was not a good idea since
taint_proper() adds extra args before it actually calls a printf-style
function. This was masked since on some gcc systems, a NULLOK format arg
disables this check.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Due to the security risks associated with user-supplied formats
being passed to C-level printf() style functions (eg %n),
gcc has a -Wformat-nonliteral warning that complains whenever such a
function is passed a non-literal format string.
This commit silences all such warnings in core and ext/.
The main changes are
1) the 'f' (format) flag in embed.fnc is now handled slightly more
cleverly. Rather than just applying to functions whose last arg is '...'
(and where the format arg is assumed to be the previous arg), it
can now handle non-'...' functions: arg checking is disabled, but format
checking is sill done: it works by assuming that an arg called 'fmt',
'pat' or 'f' is the format string (and dies if fails to find exactly one
such arg).
2) with the new embed.fnc functionally, more functions have been marked
with the 'f' flag. When such a function passes its fmt arg onto an inner
printf-like function, we simply disable the warning for that call using
GCC_DIAG_IGNORE(-Wformat-nonliteral), since we know that the caller must
have already checked it.
3) In quite a few places the format string isn't literal, but it *is*
constant (e.g. PL_warn_uninit_sv). For those cases, again disable the
warning.
4) In pp_formline(), a particular format was was one of several different
literal strings depending on circumstances. Rather than assigning this
string to a temporary variable, incorporate the ?: branches directly in
the function call arg. gcc is clever enough to decide the arg is then
always literal.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The code dealt rather inconsistently with uids and gids. Some
places assumed that they could be safely stored in UVs, others
in IVs, others in ints; All of them should've been using the
macros from config.h instead. Similarly, code that created
SVs or pushed values into the stack was also making incorrect
assumptions -- As a point of reference, only pp_stat did the
right thing:
#if Uid_t_size > IVSIZE
mPUSHn(PL_statcache.st_uid);
#else
# if Uid_t_sign <= 0
mPUSHi(PL_statcache.st_uid);
# else
mPUSHu(PL_statcache.st_uid);
# endif
#endif
The other places were potential bugs, and some were even causing
warnings in some unusual OSs, like haiku or qnx.
This commit ammends the situation by introducing four new macros,
SvUID(), sv_setuid(), SvGID(), and sv_setgid(), and using them
where needed.
|
|
|
|
|
| |
The are lots of places where local vars aren't used when compiled
with NO_TAINT_SUPPORT.
|
|
|
|
| |
The latter is more clearly named to indicate it includes the underscore.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
By defining NO_TAINT_SUPPORT, all the various checks that perl does for
tainting become no-ops. It's not an entirely complete change: it doesn't
attempt to remove the taint-related interpreter variables, but instead
virtually eliminates access to it.
Why, you ask? Because it appears to speed up perl's run-time
significantly by avoiding various "are we running under taint" checks
and the like.
This change is not in a state to go into blead yet. The actual way I
implemented it might raise some (valid) objections. Basically, I
replaced all uses of the global taint variables (but not PL_taint_warn!)
with an extra layer of get/set macros (TAINT_get/TAINTING_get).
Furthermore, the change is not complete:
- PL_taint_warn would likely deserve the same treatment.
- Obviously, tests fail. We have tests for -t/-T
- Right now, I added a Perl warn() on startup when -t/-T are detected
but the perl was not compiled support it. It might be argued that it
should be silently ignored! Needs some thinking.
- Code quality concerns - needs review.
- Configure support required.
- Needs thinking: How does this tie in with CPAN XS modules that use
PL_taint and friends? It's easy to backport the new macros via PPPort,
but that doesn't magically change all code out there. Might be
harmless, though, because whenever you're running under
NO_TAINT_SUPPORT, any check of PL_taint/etc is going to come up false.
Thus, the only CPAN code that SHOULD be adversely affected is code
that changes taint state.
|
|
|
|
|
| |
This updates the editor hints in our files for Emacs and vim to request
that tabs be inserted as spaces.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently we cache the UID/GID and effective UID/GID similarly to how
we used to cache getpid() before v5.14.0-251-g0e21945. Remove this
magical behavior in favor of always calling getpid(), getgid()
etc. This resolves RT #96208.
A minimal testcase for this is the following by Leon Timmermans
attached to RT #96208:
eval { require 'syscall.ph'; 1 } or eval { require 'sys/syscall.ph'; 1 } or die $@;
if (syscall(&SYS_setuid, $ARGV[0] + 0 || 1000) >= 0 or die "$!") {
printf "\$< = %d, getuid = %d\n", $<, syscall(&SYS_getuid);
}
I.e. if we call the sete?[ug]id() functions unbeknownst to perl the
$<, $>, $( and $) variables won't be updated. This results in the same
sort of issues we had with $$ before v5.14.0-251-g0e21945, and
getppid() before my v5.15.7-407-gd7c042c patch.
I'm completely eliminating the PL_egid, PL_euid, PL_gid and PL_uid
variables as part of this patch, this will break some CPAN modules,
but it'll be really easy before the v5.16.0 final to reinstate
them. I'd like to remove them to see what breaks, and how easy it is
to fix it.
These variables are not part of the public API, and the modules using
them could either use the Perl_gete?[ug]id() functions or are working
around the bug I'm fixing with this commit.
The new PL_delaymagic_(egid|euid|gid|uid) variables I'm adding are
*only* intended to be used internally in the interpreter to facilitate
the delaymagic in Perl_pp_sassign. There's probably some way not to
export these to programs that embed perl, but I haven't found out how
to do that.
|
| |
|
|
|
|
|
| |
Replace ckWARN_d{,2,3,4}() && Perl_warner() with it, which trades reduced code
size for 1 more function call if warnings are not enabled.
|
|
|
|
|
|
| |
Message-ID: <25940.1225611819@chthon>
Date: Sun, 02 Nov 2008 01:43:39 -0600
p4raw-id: //depot/perl@34698
|
|
|
|
|
| |
Perl_sv_magicext(), which is documented.
p4raw-id: //depot/perl@34671
|
|
|
| |
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
|
|
|
|
|
|
| |
Message-ID: <20080129124723.GA13056@refcnt.homeunix.org>
Date: Tue, 29 Jan 2008 13:47:23 +0100
p4raw-id: //depot/perl@33228
|
|
|
| |
p4raw-id: //depot/perl@32237
|
|
|
|
|
|
| |
on by default, without having to play games with the
warning bits. Add a test for -t.
p4raw-id: //depot/perl@29717
|
|
|
|
|
| |
(bug #39832)
p4raw-id: //depot/perl@28591
|
|
|
|
|
| |
did not update)
p4raw-id: //depot/perl@26732
|
|
|
|
|
| |
Message-ID: <20060106155719.GB9035@petdance.com>
p4raw-id: //depot/perl@26676
|
|
|
|
|
| |
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@26001
|
|
|
|
|
| |
Message-ID: <20050623190423.GA13835@petdance.com>
p4raw-id: //depot/perl@24965
|
|
|
| |
p4raw-id: //depot/perl@24800
|
|
|
| |
p4raw-id: //depot/perl@24760
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
Message-ID: <B356D8F434D20B40A8CEDAEC305A1F2453D653@esebe105.NOE.Nokia.com>
p4raw-id: //depot/perl@24271
|
|
|
|
|
| |
Message-ID: <20050325204331.GA16388@petdance.com>
p4raw-id: //depot/perl@24079
|
|
|
|
|
| |
Message-Id: <2f14220e7101a03f7659dbe79a03b115@petdance.com>
p4raw-id: //depot/perl@24074
|
|
|
| |
p4raw-id: //depot/perl@23176
|
|
|
|
|
|
|
| |
This error is thrown when taint checks are enabled and
when *ENV has been aliased, so that %ENV has no env-magic
anymore. (see bug [perl #24291].)
p4raw-id: //depot/perl@21563
|
|
|
|
|
|
|
| |
glob assignment, TAINT_ENV() may dump core because it
assumes $ENV{PATH} is magical. Fix this ; add a test to
verify that the PATH is still checked for taintedness.
p4raw-id: //depot/perl@21542
|
|
|
|
|
|
|
| |
(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
|
|
|
|
|
| |
safe in $ENV{TERM} for taint checkings.
p4raw-id: //depot/perl@18261
|
|
|
|
|
|
| |
From: "Paul Marquess" <paul_marquess@yahoo.co.uk>
Message-ID: <AIEAJICLCBDNAAOLLOKLMEEGDPAA.paul_marquess@yahoo.co.uk>
p4raw-id: //depot/perl@15155
|
|
|
|
|
|
| |
be found in the repository, which is most often not right,
but at least consistent)
p4raw-id: //depot/perl@14400
|
|
|
|
|
| |
and printf them as such.
p4raw-id: //depot/perl@13871
|