summaryrefslogtreecommitdiff
path: root/doio.c
Commit message (Collapse)AuthorAgeFilesLines
* Fix -Wformat-security issuesNiko Tyni2013-05-101-2/+2
| | | | | | | | Building with -Accflags="-Wformat -Werror=format-security" triggers format string warnings from gcc. As gcc can't tell that all the strings are constant here, explicitly pass separate format strings to make it happy.
* silence warnings under NO_TAINT_SUPPORTDavid Mitchell2013-05-091-0/+2
| | | | | The are lots of places where local vars aren't used when compiled with NO_TAINT_SUPPORT.
* Restore the warning previously issued by (-l $fh)Ricardo Signes2013-05-081-2/+7
| | | | | | | | | | This is a partial reversion of 433644eed8, which removed a secondary, short-circuiting behavior when the warning was issued. Now, the warning is issued, but the normal behavior (treat the handle as a string) is maintained. This work was done after subsequent refactoring to doio.c, so it couldn't be just a reversion with the "return" statement removed.
* Add return statements where missing in doio.c IPC functions.Craig A. Berry2013-03-031-0/+3
| | | | | | | | These are code paths not seen on platforms that have msg* and shm* functions, and of course we're croaking before returning so returning is pointless, but the VMS C compiler insists that we have return statments for non-void functions anyway, and that compiler now sees these functions since enabling sem*.
* Change core calls of isALNUM() to isWORDCHAR()Karl Williamson2012-12-311-1/+1
| | | | The latter is more clearly named to indicate it includes the underscore.
* doio.c: Use SvREFCNT_dec_NNFather Chrysostomos2012-12-091-1/+1
| | | | | | The sole use of SvREFCNT_dec in doio.c is on a variable than is never null (setdefout would fail an assertion otherwise), so no need to check whether it is.
* Silence some g++ compiler warningsKarl Williamson2012-12-091-1/+1
| | | | | Changing these slightly got rid of the warnings like: toke.c:9168: warning: format not a string literal and no format arguments
* Remove "register" declarationsKarl Williamson2012-11-241-6/+6
| | | | | | | This finishes the removal of register declarations started by eb578fdb5569b91c28466a4d1939e381ff6ceaf4. It neglected the ones in function parameter declarations, and didn't include things in dist, ext, and lib, which this does include
* Remove the EPOC port.Nicholas Clark2012-11-191-1/+1
| | | | | | | EPOC was a family of operating systems developed by Psion for mobile devices. It was the predecessor of Symbian. The port was last updated in April 2002.
* Add C define to remove taint support from perlSteffen Mueller2012-11-051-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Remove thread context from Perl_vmssetuserlnm.Craig A. Berry2012-11-031-2/+2
| | | | | | | | | | | This routine by its very nature applies to the whole process so there is no way it can make use of a thread context, and it may need to be called from places where there is no thread context, such as very early in start-up. It's not documented, was never intended to be part of the API, was only made global so it could be called from doio.c, and no uses of it turn up in a CPAN grep, so the change should be safe.
* Omnibus removal of register declarationsKarl Williamson2012-08-181-12/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Magic flags harmonization.Chip Salzenberg2012-07-151-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | In restore_magic(), which is called after any magic processing, all of the public OK flags have been shifted into the private OK flags. Thus the lack of an appropriate public OK flags was used to trigger both get magic and required conversions. This scheme did not cover ROK, however, so all properly written code had to make sure mg_get was called the right number of times anyway. Meanwhile the private OK flags gained a second purpose of marking converted but non-authoritative values (e.g. the IV conversion of an NV), and the inadequate flag shift mechanic broke this in some cases. This patch removes the shift mechanic for magic flags, thus exposing (and fixing) some improper usage of magic SVs in which mg_get() was not called correctly. It also has the side effect of making magic get functions specifically set their SVs to undef if that is desired, as the new behavior of empty get functions is to leave the value unchanged. This is a feature, as now get magic that does not modify its value, e.g. tainting, does not have to be special cased. The changes to cpan/ here are only temporary, for development only, to keep blead working until upstream applies them (or something like them). Thanks to Rik and Father C for review input.
* ensure shmread() calls get and set magic onceChip Salzenberg2012-07-101-1/+2
|
* hold pid in Pid_t, not I32, for kill()Chip Salzenberg2012-07-101-2/+2
|
* Remove C++isms from doio.cSteve Hay2012-06-261-3/+3
| | | | (Introduced by c2fd40cb02 and not tolerated by VC++ compiling a C file.)
* [perl #112990] Simplify kill implementation and docsDarin McBride2012-06-261-28/+26
| | | | | | | | | | | | | | | | | | Clean up kill implementation and clear up the docs in perlfunc to be less ambiguous and encompass more of its behaviour. a) kill -INT => $pid; was surprisingly doing a "kill 0, $pid" instead of being the same as "kill -2, $pid" (killing the process group for $pid with an interrupt). Now negative signal names will be allowed and be the same as if the name was replaced with the signal number it represents. b) remove all calls to killpg() as killpg is defined in terms of kill anyway. c) Clarify the use of signal names vs numbers in perlfunc so that using names is not so well hidden, as well as explaining the usage of negative signal numbers as well as negative process IDs.
* [perl #113798] Don’t hide PATH from perlglobFather Chrysostomos2012-06-231-0/+3
| | | | | | | | | | | | | To fix another bug, miniperl was changed to clear out %ENV before shelling out to call the underlying glob program (csh on Unix; perlglob on Windows), in commit a3342be368. That proved slightly problematic, as it stopped <~> from working on Unix, so commit 93b2dae1 changed it to preserve just $ENV{HOME}. That turns out not to have been enough. For some compilers, Win- dows needs PATH preserved for perlglob to find certain DLLs it needs to load.
* Make open(... "<&", $fileno) respect magicFather Chrysostomos2012-06-071-1/+4
| | | | | | | | | | | | | | | | | A magical variable is never SvPOK, but only SvPOKp. The code for checking whether a duplicatee is a numeric file descriptor was only checking SvPOK. So a regular variable containing a fileno-as-a-string would work, such as the $a below, as would a stringified magical vari- able ("$1"), but not $1 itself. $ echo foo | perl -le '$a = "0"; open a, "<&", $a; warn <a>' foo $ echo foo | perl -le '"0" =~ /(.)/; open a, "<&", $1; warn <a>' Can't use an undefined value as filehandle reference at -e line 1. $ echo foo | perl -le '"0" =~ /(.)/; open a, "<&", "$1"; warn <a>' foo SvPOK variables are also SvPOKp, so checking only the latter suffices.
* update the editor hints for spaces, not tabsRicardo Signes2012-05-291-2/+2
| | | | | This updates the editor hints in our files for Emacs and vim to request that tabs be inserted as spaces.
* File scope for VMS-specific #includes.Craig A. Berry2012-05-241-1/+4
| | | | | C++ requires #include directives to be at file scope, but we've been lazy and haven't been doing that.
* doio.c: Add some commentsKarl Williamson2012-05-221-5/+10
|
* Move stack extension into FT_* macrosFather Chrysostomos2012-05-211-2/+0
| | | | | | | | Every filetest operator with the OPf_REF flag set has to extend the stack for the argument. One operator was missing it until the previ- ous commit. Since we have special return macros for these operators, put the stack extension there, to avoid a repeat of this type of mis- take and reduce repetitiveness.
* Make filetest ops fiddle the stack lessFather Chrysostomos2012-05-211-10/+4
| | | | | | | | | | | See commits 8db8f6b697e and d6642e439 for the background. Instead of sometimes popping items off the stack for filetest operat- ors and sometimes not, just leave the item on the stack and use SETs to return the value (which the overload code was doing already any- way). This simplifies the code and allows d6642e439 to be reverted. It also makes things theoretically faster, simply because there is less stuff happening.
* PATCH: [perl #111338] Warnings in utf8 subcategories do nothing in isolationKarl Williamson2012-04-171-1/+1
| | | | | This was the result of assuming that these would not be on unless the main category was also on.
* Remove gete?[ug]id cachingÆvar Arnfjörð Bjarmason2012-02-181-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* [perl #77388] Make stacked -t workFather Chrysostomos2012-01-231-8/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Up till now, -t was popping too much off the stack when stacked with other filetest operators. Since the special use of _ doesn’t apply to -t, we cannot simply have it use _ when stacked, but instead we pass the argument down from the previous op. To facilitate this, the whole stacked mechanism has to change. As before, in an expression like -r -w -x, -x and -w are flagged as ‘stacking’ ops (followed by another filetest), and -w and -r are flagged as stacked (preceded by another filetest). Stacking filetest ops no longer return a false value to the next op when a test fails, and stacked ops no longer check the truth of the value on the stack to determine whether to return early (if it’s false). The argument to the first filetest is now passed from one op to another. This is similar to the mechanism that overloaded objects were already using. Now it applies to any argument. Since it could be false, we cannot rely on the boolean value of the stack item. So, stacking ops, when they return false, now traverse the ->op_next pointers and find the op after the last stacked op. That op is returned to the runloop. This short-circuiting is proba- bly faster than calling every subsequent op (a separate function call for each). Filetest ops other than -t continue to use the last stat buffer when stacked, so the argument on the stack is ignored. But if the op is preceded by nothing other than -t (where preceded means on the right, since the ops are evaluated right-to-left), it *does* use the argument on the stack, since -t has not set the last stat buffer. The new OPpFT_AFTER_t flag indicates that a stacked op is preceded by nothing other than -t. In ‘-e -t foo’, the -e gets the flag, but not in ‘-e -t -r foo’, because -r will have saved the stat buffer, so -e can just use that.
* Provide as much diagnostic information as possible in "panic: ..." messages.Nicholas Clark2012-01-161-1/+2
| | | | | | | | | | | | | | | The convention is that when the interpreter dies with an internal error, the message starts "panic: ". Historically, many panic messages had been terse fixed strings, which means that the out-of-range values that triggered the panic are lost. Now we try to report these values, as such panics may not be repeatable, and the original error message may be the only diagnostic we get when we try to find the cause. We can't report diagnostics when the panic message is generated by something other than croak(), as we don't have *printf-style format strings. Don't attempt to report values in panics related to *printf buffer overflows, as attempting to format the values to strings may repeat or compound the original error.
* Make -l HANDLE set PL_laststatval with fatal warningsFather Chrysostomos2012-01-141-1/+2
| | | | | | | Fatal warnings were preventing it from being set, because the warning came first. (PL_laststatval records the success status of the previous stat.)
* Squash repetitititive code in doio.c:my_stat_flagsFather Chrysostomos2012-01-131-8/+3
|
* Make failed filetests consistent with & w/out fatal warningsFather Chrysostomos2012-01-131-2/+4
| | | | | | The result of stat(_) after a failed -r HANDLE would differ depending on whether fatal warnings are on. This corrects that, by setting the internal status before warning about an unopened filehandle.
* stat $ioref should record the handle for -T _Father Chrysostomos2012-01-131-1/+1
| | | | | | | stat $gv records the handle so that -T _ can use it. But stat $ioref hasn’t been doing that, until this commit. PL_statgv can now hold an SVt_PVIO instead of a SVt_PVGV.
* Make <~> work again under miniperlFather Chrysostomos2011-10-241-1/+7
| | | | | | | | | | | | Commit a3342be368 localised %ENV before calling csh for glob. But that causes <~> to stop working. So this commit clears out %ENV *except* for $ENV{HOME}. It relies on the way magic works: Before localising the %ENV hash, it retrieves its $ENV{HOME} element, which is a magical scalar. It calls get-magic to store the value in the scalar itself, localises %ENV, and then calls set-magic on the element, to signal (deceitfully) that an assignment has just happened. So the cached value in the magical sca- lar is used and assigned to the env var.
* Use HEKfFather Chrysostomos2011-10-071-8/+12
| | | | This avoids creating a lot of temporary SVs.
* whichsig nul-cleanup.Brian Fraser2011-10-061-4/+7
| | | | | This adds _pv, _pvn, and _pv versions of whichsig() in mg.c, which get both kill "NAME" and %SIG lookup nul-clean.
* doio.c: Make warnings UTF8- and nul-cleanBrian Fraser2011-10-061-8/+8
|
* Only upgrade when necessaryLeon Timmermans2011-09-181-1/+1
|
* Make -l always treat non-bareword arguments as file namesFather Chrysostomos2011-09-171-5/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Here is some suspicious code in Perl_my_lstat_flags: if (SvROK(sv) && isGV_with_GP(SvRV(sv)) && ckWARN(WARN_IO)) { Perl_warner(aTHX_ packWARN(WARN_IO), "Use of -l on filehandle %s", GvENAME((const GV *)SvRV(sv))); return (PL_laststatval = -1); } The behaviour differs depending on whether warnings are enabled. That -1 turns into undef in pp_ftlink. So we get an undef return value with warnings on, but a file test on a file name otherwise. In 5.6.2, -l $foo always treated $foo as a file name. In 5.8+, if it is a reference (ignoring magic) and the reference points to a typeglob (ignoring magic) and io warnings are on, it warns and returns undef. So the only time that undef return is reached is when a warning has been emitted, so it’s code that will likely be corrected before it goes into production. Hence I think it unlikely that anyone could be relying on the behaviour of -l \*foo (under warnings). So this commit restores the 5.6 behaviour for that case.
* Make stacked -l workFather Chrysostomos2011-09-171-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Perl 5.10.0 introduced stacked filetest operators, -x -r $foo being equivalent to -r $foo && -x _ That does not work with -l. It was these suspicious lines in Perl_my_lstat_flags that drew my attention to it: > else if (PL_laststype != OP_LSTAT > && (PL_op->op_private & OPpFT_STACKED) && ckWARN(WARN_IO)) > Perl_croak(aTHX_ no_prev_lstat); That croak only happens when warnings are on. Warnings are just supposed to be warnings, unless the ‘user’ explicitly requests fatal warnings. $ perl -le 'print "foo", -l -e "miniperl"' foo $ perl -lwe 'print "foo", -l -e "miniperl"' The stat preceding -l _ wasn't an lstat at -e line 1. That it doesn’t die in the first example is a bug. In fact, it’s using the return value of -e as a file name: $ ln -s miniperl 1 $ ./miniperl -le 'print -l -e "miniperl"' 1 And, with warnings on, if the preceding stat *was* an lstat, it falls back to the pre-stacked behaviour, just as it does when warn- ings are off. It’s meant to be equivalent to -e "miniperl" && -l _ (which is why the error message above says ‘The stat preceding -l _’).
* [perl #93638] $ENV{LS_COLORS} causes miniperl glob failureFather Chrysostomos2011-09-161-0/+1
| | | | | | | | | On some systems, csh croaks if the LS_COLORS envvar contains something it considers invalid. The easiest and least intrusive fix for now is to localize %ENV before running csh, though eventually it might be nice to use File::Glob in miniperl, either by linking it statically or by inlining it.
* Fix #98480 math when reading shared memoryLeon Timmermans2011-09-141-1/+2
| | | | | shmread didn't unset SvIOK properly, causing a read into a SVIV to have an incorrect numeric value. This patch fixes that and adds tests.
* Make utime handle get-magic correctly for glob(ref)sFather Chrysostomos2011-09-101-8/+2
| | | | It used to ignore get-magic for globs and globrefs.
* Make filetest ops handle get-magic correctly for glob(ref)sFather Chrysostomos2011-09-101-6/+1
| | | | | | This patch uses the recently-added MAYBE_DEREF_GV macro which puts the glob deref logic in one spot. It also adds _nomg and _flags varia- tions of it. _flags understands the SV_GMAGIC flag.
* -l followed by bareword should leave the stack aloneFather Chrysostomos2011-09-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | $ ln -s /usr/bin/perl bar $ perl -le' print "bar", -l foo' 1 The -l ate my bar. It’s this naughty piece of code in doio.c:Perl_my_lstat_flags that is the culprit: if (ckWARN(WARN_IO)) { Perl_warner(aTHX_ packWARN(WARN_IO), "Use of -l on filehandle %s", GvENAME(cGVOP_gv)); return (PL_laststatval = -1); } When -l is followed by a bareward, it has no argument on the stack, but the filetest op itself is a gvop. That snippet is from the bare- word-handling code. So, if warnings are off, it falls through to the argument-on-the-stack code and pops off something does not belong to it (that belong to the print, in the example above).
* The Borland Chainsaw MassacreSteve Hay2011-09-101-3/+0
| | | | | Remove support for the Borland C++ compiler on Win32, as agreed here: http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2011-09/msg00034.html
* ch(dir|mod|own) should also call FETCH on refs to tied globsFather Chrysostomos2011-09-101-16/+2
| | | | | | | | Following on from commit 935647290357b277, which corrected the beha- viour for tied globs, this commit corrects the behaviour for refer- ences to tied globs. (With tests by Nicholas Clark.)
* ch(dir|mod|own) should not ignore get-magic on glob(ref)sFather Chrysostomos2011-09-081-2/+4
| | | | | | | | When the chdir(*handle) feature was added in 5.8.8, the fact that globs and refs could be magical was not taken into account. They can easily be magical if a typeglob or reference is returned from or assigned to a tied variable.
* Add check_utf8_print()Karl Williamson2011-01-091-0/+6
| | | | | | | This new function looks for problematic code points on output, and warns if any are found, returning FALSE as well. What it warns about may change, so is marked as experimental.
* Fix typos (spelling errors) in Perl sources.Peter J. Acklam) (via RT2011-01-071-1/+1
| | | | | | | | | # New Ticket Created by (Peter J. Acklam) # Please include the string: [perl #81904] # in the subject line of all future correspondence about this issue. # <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=81904 > Signed-off-by: Abigail <abigail@abigail.be>
* GvIO(gv) returns NULL for a NULL gv, so refactor to take advantage of this.Nicholas Clark2011-01-021-6/+6
| | | | | | Simplify tests of !gv || !io to just !io, avoid calling GvIO(gv) more than once, and where possible initialise io at declaration time, to allow it to be const.
View Lorry Controller Status