summaryrefslogtreecommitdiff
path: root/pp_sys.c
Commit message (Collapse)AuthorAgeFilesLines
* Call FETCH once for stacked filetest opsFather Chrysostomos2012-01-241-1/+1
|
* [perl #77388] Make stacked -t workFather Chrysostomos2012-01-231-86/+108
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Warn for stat(*unopened) after statting fileFather Chrysostomos2012-01-201-0/+1
| | | | | | | | | Statting an existing file used to prevent a subsequent stat(*unopened) from warning if the GV happened to have no IO. If the GV *did* have an IO, but an unopened one, it *would* warn. This inconsistency was introduced in 5.10.0 with commit 5228a96c60 (which was also backported to 5.8.9).
* pp_sys.c:pp_stat: Change scope of havefp varFather Chrysostomos2012-01-201-2/+2
| | | | | This is only used in the if(gv != PL_defgv) block now. Also, it was being used uninitialized for bad iorefs, probably resulting in random warning suppression (untested).
* [perl #71002] stat() on unopened fh _Father Chrysostomos2012-01-201-1/+1
| | | | | | | | stat _ was producing an erroneous warning about an unopened filehandle with _. But _ isn’t a real filehandle and is special-cased, so it shouldn’t warn. See also commit 8080e3c8.
* pp_sys.c: compiler warningFather Chrysostomos2012-01-191-1/+1
|
* Provide as much diagnostic information as possible in "panic: ..." messages.Nicholas Clark2012-01-161-1/+1
| | | | | | | | | | | | | | | 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 lstat($ioref) and lstat($gv) consistentFather Chrysostomos2012-01-141-7/+4
| | | | | | | As documented in perldiag, lstat($gv) warns and does an fstat. lstat($ioref) wasn’t doing what was documented, but after warning would do the same as stat(_).
* pp_sys.c: goto mustn’t skip initialisationFather Chrysostomos2012-01-141-1/+2
|
* -T "unreadable file" should set stat info consistentlyFather Chrysostomos2012-01-141-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | This was mentioned in ticket #77388. It turns out to be related to #4253. If the file cannot be opened, -T and -B on filenames set the last han- dle to null and set the last stat type to stat, but leave the actual stat buffer and success status as they were. That means that stat(_) will continue to return the previous buffer, but lstat(_) will no longer work. This is another of those inconsistent cases where the internal stat info is only partially set. Originally, this code would set PL_laststatval (the success status) to -1. Commit 25988e07 (the patch in ticket #4253) intentionally changed this to make -T _ less suprising on read-only files. But the patch ended up affecting -T with an explicit file name, too. It also only partially fixed things for -T _, because the last stat type *was* still being set. This commit changes it to set all the stat info, for explicit file names, or no stat info, for _ (if the previous stat was with a file name).
* Don’t emit unopened warning for other stat(HANDLE) errorFather Chrysostomos2012-01-141-1/+4
| | | | | | | | | | | | | -r or -T on a GV with no IO or on an IO with no fp (or dirp for -r) will produce an ‘unopened’ warning. stat() on a filehandle will warn about an unopened filehandle not only if there is no fp, but also if the fstat call fails (with errno containing EBADP, EFAULT or EIO, at least on Darwin). I don’t know if there is a way to test this. (But pp_stat and my_stat_flags are getting closer, so this must be correct. :-)
* Make -T BADHANDLE set errno with fatal warningsFather Chrysostomos2012-01-141-0/+1
| | | | | | | | | | | Due to the order of the statements, SETERRNO would never be reached with fatal warnings. I’ve added another SETERRNO out of paranoia. If there is a nicely- behaved __WARN__ handler, we should still be setting errno just before -T returns, in case the handler changed it. We can’t do much in the case of fatal handlers that do system calls. (Is $! localised for those?)
* Make -T HANDLE and -B HANDLE always set last stat typeFather Chrysostomos2012-01-131-1/+1
| | | | | | | | -T and -B on handles always set PL_laststatval (which indicates the success of the previous stat). But they don’t set the last stat type (PL_laststype) for closed filehandles. Those two should always go together. stat and -r, -w etc., always set PL_laststype for a closed or missing filehandle.
* pp_sys.c:pp_fttest: Don’t set PL_statname to SvPV(PL_statname)Father Chrysostomos2012-01-131-2/+1
| | | | | | This is a waste of CPU cycles. PL_statname is always a PV.
* Make -T _ and -B _ always set PL_laststatvalFather Chrysostomos2012-01-131-1/+1
| | | | | | | | | | | | -T _ and -B _ always do another stat() on the previous file handle or filename, unless it is a handle that has been closed. Normally, the internal stat buffer, status, etc., are reset even for _. This happens even on a failed fstat(). -T HANDLE and -B HANDLE currently *do* reset the stat status (PL_laststatval) if there is no IO thingy, so having -T _ and -B _ not do that makes things needlessly inconsistent.
* pp_sys.c: Remove space from lstat($ioref) warningFather Chrysostomos2012-01-131-1/+3
| | | | | | This was emitting two spaces before the ‘at’: lstat() on filehandle at -e line 1.
* pp_sys.c:pp_fttext: Don’t extend the stack after poppingFather Chrysostomos2012-01-131-1/+3
|
* stat $ioref should record the handle for -T _Father Chrysostomos2012-01-131-1/+5
| | | | | | | 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.
* stat $ioref should reset the internal stat typeFather Chrysostomos2012-01-131-0/+1
| | | | | | | | In addition to a stat buffer, Perl keeps track internally of which type of stat was done last, either stat or lstat, so that lstat _ can die if the previous type was stat. This was not being reset for stat $ioref. Filetest ops were fine.
* Make -T HANDLE set the last stat typeFather Chrysostomos2012-01-121-0/+1
| | | | This was brought up in bug #77388.
* Simplify logic in pp_sys.c:pp_ftttyFather Chrysostomos2012-01-121-7/+2
| | | | | name is only set when there is no gv. As of a couple of commits ago, tmpsv is only used in that else block where it is set.
* [perl #77388] Make stacked -T and -B workFather Chrysostomos2012-01-121-0/+2
| | | | | | They just need to pick up the _ filehandle in stacked mode, like the other ops (which actually rely on my_stat[_flags] to do it). This apparently was forgotten when stacked filetests were added.
* Make -t, -T and -B with a handle pop it off the stackFather Chrysostomos2012-01-121-6/+7
| | | | | | This is something I broke carelessly with commit 094a3eec8. No, this does not fix bug #77388.
* In pp_sys.c:pp_fttext, don’t call cGVOP_gv on an UNOPFather Chrysostomos2012-01-121-1/+1
| | | | | | | | | | | | | | | | | | | | Otherwise we might get a crash. cGVOP_gv is only valid when the OPf_REF flag is set. In either case, gv already holds the GV we want anyway. This code has been buggy this way since this commit: commit 5f05dabc4054964aa3b10f44f8468547f051cdf8 Author: Perl 5 Porters <perl5-porters@africa.nicoh.com> Date: Thu Dec 19 16:44:00 1996 +1200 [inseparable changes from patch from perl5.003_11 to perl5.003_12] but apparently has not actually caused a crash until just now. I was trying to add a test for another bug (fixed in the next commit), and it happened to trigger this one. My attempt to reduce this to something small and reproducible failed.
* [perl #90064] warn once for dbmopen with undef 3rd argFather Chrysostomos2012-01-051-0/+3
|
* Block SIGCHLD during system() call (per POSIX)Leon Timmermans2011-12-311-0/+17
|
* diag_listed_as galoreFather Chrysostomos2011-12-281-0/+7
| | | | | In two instances, I actually modified to code to avoid %s for a constant string, as it should be faster that way.
* Turn on AvREAL for tied arraysFather Chrysostomos2011-12-271-0/+7
| | | | | | | | | | | | | It turns out that it is possible to trigger the av_reify warning: ./perl -Ilib -lwe ' sub TIEARRAY{bless[]} sub { tie @_, ""; \@_; }->(1); ' av_reify called on tied array at -e line 7.
* select() can return undef when defoutgv is setFather Chrysostomos2011-12-241-9/+5
| | | | | | | | | | | If PL_defoutgv has been deleted from its stash, select() returns it as a ref, but if the stash has been freed (even though the gv still exists), it returns undef. That makes no sense. This is one of those nice cases where simplifying the code fixes a bug.
* select() sometimes returns invalid stringFather Chrysostomos2011-12-241-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | The return value from select() is sometimes a string, and sometimes a globref. It was originally always a string, but typeglobs not to be found under their names in their stashes started being returned as references in 5.002 beta 1 (4633a7c4b). The logic is a little faulty, though, as sometimes the name that is returned cannot be used to find the glob: $ perl -le ' open "foo::bar", ">/dev/ttys009"; select foo::bar; my $handle = \*foo::bar; my $stash = \%foo::bar; *foo:: = *bar::; print "hello"; select select; print "hello" or warn $! ' Bad file descriptor at -e line 9. In this example, /dev/ttys009 is another terminal window. "hello" only appears once, not twice.
* [perl #97980] Stop tied() from returning a copyFather Chrysostomos2011-11-261-4/+1
| | | | | Now tied() returns the actual scalar used to hold the tie object, so one can write weaken(tied $foo).
* Make sselect call fetch onceFather Chrysostomos2011-11-241-2/+5
| | | | | | | Not only does this commit make four-argument select call fetch once on each argument (instead of sometimes 0 times), but it also checks whether the argument is a string after calling fetch now, instead of before, in determining whether to warn about a non-string.
* Avoid a redundant copy in pp_globFather Chrysostomos2011-11-191-3/+3
| | | | | Most of the time, the argument to glob() won’t be tied, so we don’t need to copy it. So only copy it if it is gmagical.
* Fix CORE::globFather Chrysostomos2011-10-261-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | This commit makes CORE::glob bypassing glob overrides. A side effect of the fix is that, with the default glob implementa- tion, undefining *CORE::GLOBAL::glob no longer results in an ‘unde- fined subroutine’ error. Another side effect is that compilation of a glob op no longer assumes that the loading of File::Glob will create the *CORE::GLOB::glob type- glob. ‘++$INC{"File/Glob.pm"}; sub File::Glob::csh_glob; eval '<*>';’ used to crash. This is accomplished using a mechanism similar to lock() and threads::shared. There is a new PL_globhook interpreter varia- ble that pp_glob calls when there is no override present. Thus, File::Glob (which is supposed to be transparent, as it *is* the built-in implementation) no longer interferes with the user mechanism for overriding glob. This removes one tier from the five or so hacks that constitute glob’s implementation, and which work together to make it one of the buggiest and most inconsistent areas of Perl.
* Use HEKfFather Chrysostomos2011-10-071-16/+16
| | | | This avoids creating a lot of temporary SVs.
* use SSize_t for string offsets instead of int or socklen_tTony Cook2011-10-071-6/+8
| | | | | | | | | | | | | | | | | | | | Note: while I discovered the incorrect types while investigating [perl described in that report, so I don't consider this a fix for that bug. Unfortunately to test this change I'd need a scalar at least 2G in size, which unreasonable for a test we run on each install. Tested manually on a machine with plenty of memory: Before: [tonyc@dromedary perl]$ echo foo | ./perl -le '$x = ""; read(STDIN, $x, 4, 5000000000); print length $x' 705032708 After: [tonyc@dromedary perl]$ echo foo | ./perl -le '$x = ""; read(STDIN, $x, 4, 5000000000); print length $x' 5000000004
* pp_sys.c: pp_select UTF8 cleanup.Brian Fraser2011-10-061-1/+1
|
* pp_sys.c: Make warnings utf8-cleanBrian Fraser2011-10-061-19/+23
|
* pp_sys.c: pp_tie and untie UTF8 cleanup.Brian Fraser2011-10-061-4/+2
|
* Make stacked -l workFather Chrysostomos2011-09-171-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 _’).
* Don't #include headers already included by perl.hNicholas Clark2011-09-151-4/+0
| | | | | | | | | 097ee67dff1c60f2 didn't need to include <locale.h> in locale.c (then util.c) because it had been included by perl.h since 5.002 beta 1 3f270f98f9305540 missed removing the include of <unistd.h> from perl.c or perlio.c de8ca8af19546d49 changed perl.h to also include <sys/wait.h>, but didn't notice that it code therefore be removed from perl.c, pp_sys.c and util.c
* Add diag_listed_as for lstat error msgFather Chrysostomos2011-09-121-0/+1
| | | | to let porting/diag.t know how it’s listed in perldiag.
* Make (l)stat respect get-magic on globs and globrefsFather Chrysostomos2011-09-121-14/+5
| | | | | | | | | | | | | | | They were ignoring get-magic for those. A side effect of this fix is that lstat filehandle warnings and errors are now consistent: lstat _ used to die if the previous stat was not an lstat, but lstat *_ and lstat \*_ would happily return what was in the buffer. Now they die. lstat FH and \*FH used to warn, but not lstat *FH. Now it does. See bug #98864.
* Make truncate respect get-magic on globs and globrefsFather Chrysostomos2011-09-111-20/+8
| | | | It was ignoring get-magic for those.
* Stop filetest ops from calling FETCH on parent op’s argFather Chrysostomos2011-09-101-2/+2
| | | | | | | | | | | | | This is a regression in 5.14.0. Commit 6f1401dc made ops call get-magic before overloading, but it ended up making filetest ops call get-magic on the topmost item of the stack even if the filetest op was not going to use the stack (which happens for ‘-r bareword’ and plain ‘-r’). This would affect cases like: push @foo, $tied, -r;
* Make filetest ops handle get-magic correctly for glob(ref)sFather Chrysostomos2011-09-101-11/+2
| | | | | | 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.
* ch(dir|mod|own) should also call FETCH on refs to tied globsFather Chrysostomos2011-09-101-11/+1
| | | | | | | | 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.)
* In pp_chdir, move SvGETMAGIC(sv) out of the if() condition.Nicholas Clark2011-09-091-7/+10
| | | | | | It was added to the if() condition as part of 935647290357b277. Unfortunately the syntax used to implemented SvGETMAGIC(sv) is considered by gcc to be valid in an expression, but is not valid in other compilers.
* ch(dir|mod|own) should not ignore get-magic on glob(ref)sFather Chrysostomos2011-09-081-2/+2
| | | | | | | | 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.
* &CORE::umask()Father Chrysostomos2011-08-291-2/+2
| | | | | | | | This commit allows &CORE::umask to be called through references and via ampersand syntax. pp_umask is modified to take into account the nulls pushed on to the stack in pp_coreargs, which happens because pp_coreargs has no other way to tell umask how many arguments it’s actually getting. See commit 0163043a for details.
View Lorry Controller Status