summaryrefslogtreecommitdiff
path: root/pp_sys.c
Commit message (Collapse)AuthorAgeFilesLines
* Omnibus removal of register declarationsKarl Williamson2012-08-181-39/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Don’t crash when undefining handle of active formatFather Chrysostomos2012-08-051-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | format FOO = @ undef *STDOUT . $~ = FOO; write Commit 7ef822cddfe9 began the work by putting in a null check and a goto (to bypass the top format), but the goto wentto some code that lacked the null check. (It did actually fix the case of a IO with no ofp, but not the case of a GV with no IO.) Interestingly, it added a bad_ofp label, but did not add the code to goto it (an oversight?). The unused bad_ofp label was commented out in commit 9cbac4c72b52. There was already a check before 7ef822cddfe9 to see whether there was an ofp, but only after the format scope has been popped. This commit extends that check by making sure there is an io first. It removes the commented-out bad_ofp label.
* Recursive formats and closures in formats.Father Chrysostomos2012-08-051-1/+5
| | | | | | | | | | | | | | Formats called recursively were using the same set of lexicals, so the inner call would stomp on the outer calls vars, usually clearing them when exiting. Previous commits prepared a CvDEPTH field for formats. This commit sets it in P(USH|OP)FORMAT and pushes a new pad in enterwrite. This also allows closures to work properly in formats. Formerly they caused assertion failures in cv_clone. Now cv_clone’s assumptions about CvDEPTH on CvOUTSIDE and find_runcv are met when subs are embed- ded in formats.
* Remove dead code related to the Atari ST port of perl 4.0 patchlevel 19Nicholas Clark2012-07-281-32/+0
| | | | | The subdirectory containing the port specific files was purged when 5.000 was released, but changes made to other files were not removed.
* Comment the code with how filetest operators interact with the Perl stack.Nicholas Clark2012-07-281-0/+7
|
* Eliminate the macros FT_RETURN_FALSE() and FT_RETURN_TRUE().Nicholas Clark2012-07-281-12/+7
| | | | | | As they now simply return the results of S_ft_return_false() and S_ft_return_true() respectively, use this explicitly in the 7 places where the macros had been used.
* Refactor the macro FT_RETURN_TRUE() into the function S_ft_return_true()Nicholas Clark2012-07-281-12/+12
| | | | | This makes the true and false code paths as similar as possible. It also eliminates a macro that the HP compiler was choking on.
* Consolidate the code for returning false values from filetest operators.Nicholas Clark2012-07-281-12/+7
| | | | | | Move the code that implements the non-stacking return processing from the macro FT_RETURN_FALSE() into the static function S_ft_stacking_return_false(). Rename the function to S_ft_return_false() as it now handles all false cases.
* Reorder S_ft_stacking_return_false().Nicholas Clark2012-07-281-4/+6
| | | | | | Move the code which deals with setting the return value on perl's stack ahead of the code which calculates which op to run next (the return value of the C function).
* Remove dSP from all filetest ops.Nicholas Clark2012-07-281-13/+8
| | | | | | | | | | Following commit d2c4d2d1e22d3125, all filetest ops avoid manipulating the stack pointer until the point of pushing a return value. As all the filetest returns now go through either FT_RETURN_FALSE() or FT_RETURN_TRUE(), it's viable to put the dSP inside those two macros and use *PL_stack_sp in place of TOPs. This eliminates all uses of sp in the bodies of the functions (explicit, or implicit via macros), and that makes it clear that the main bodies of the functions are not manipulating the stack.
* Replace the macro RETURNX() with its expansion in FT_RETURN_{FALSE,TRUE}Nicholas Clark2012-07-281-8/+14
| | | | | | | | The macros FT_RETURN_FALSE and FT_RETURN_TRUE in pp_ctl.c are already very complex, sufficient to trigger an internal failure in HP's compiler [and possibly also some humans :-)]. Replacing RETURNX() with the 3 statements it expands to makes the intent of macros clearer, and exposes more refactoring possibilities.
* [perl #113872] Fix leavewrite’s stack handlingFather Chrysostomos2012-07-261-8/+2
| | | | | | | | | | | | | This commit fixes Scope::Escape compatibility by restoring the old stack pointer stored on the context stack when exiting a write. I don’t really understand why this fixes Scope::Escape, or rather, how Scope::Escape ends up leaving some number of items on the stack other than 1. But I *do* know this is the correct approach, as it mirrors what pp_leavesub does in scalar context, but pops the stack back to the old value (SP = newsp), rather than the old value+1 (see pp_hot.c:pp_leavesub: MARK = newsp + 1; and later SP = MARK;). Then the code that follows takes care of pushing write’s own return value.
* Stop truncate(word) from falling back to file nameFather Chrysostomos2012-07-251-3/+3
| | | | | | | | | In commit 5e0adc2d66, which was a bug fix, I made the mistake of checking the truth of the return value of gv_fetchsv, which is called when truncate’s argument is a bareword. This meant that truncate FOO, 0; would truncate the file named FOO if the glob happened to have been deleted.
* Magic flags harmonization.Chip Salzenberg2012-07-151-7/+12
| | | | | | | | | | | | | | | | | | | | | | | | | 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.
* use right type for offset in sysread() or syswrite()Chip Salzenberg2012-07-111-1/+1
|
* [perl #113980] pp_syscall: "I32 retval" truncates the returned valueOleg Nesterov2012-07-041-1/+1
| | | | | | | | | I noticed today that syscall(9, ...) (mmap) doesn't work for me. The problem is obvious, pp_syscall() uses I32 for retval and the "long" address doesn't fit into "int". The one-liner below should fix the problem.
* propagate context into overloads [perl #47119]Jesse Luehrs2012-06-281-1/+1
| | | | | | | | | | | | | | | | | amagic_call now does its best to propagate the operator's context into the overload callback. It's not always possible - for instance, dereferencing and stringify/boolify/numify always have to return a value, even if it's not used, due to the way the overload callback works in those cases - but the majority of cases should now work. In particular, overloading <> to handle list context properly is now possible. For backcompat reasons (amagic_call and friends are technically public api functions), list context will not be propagated unless specifically requested via the AMGf_want_list flag. If this is passed, and the operator is called in list context, amagic_call returns an AV* holding all of the returned values instead of an SV*. Void context always results in amagic_call returning &PL_sv_undef.
* pp_sys.c: Squelch compiler warningFather Chrysostomos2012-06-251-1/+1
|
* fix stack handling in write() [perl #73690]Jesse Luehrs2012-06-251-4/+9
| | | | | | | I'm not sure about that POPs at the beginning of pp_leavewrite, but it seems to work. As far as I can tell, executing the format always leaves an extra value on the stack, but I'm not sure where that happens exactly, so I'm just fixing it up there.
* Make warn treat $@=3 and $@="3" the sameFather Chrysostomos2012-06-071-1/+1
| | | | | | | | | | | | | | If we get this: $ ./perl -Ilib -e '$@ = "3"; warn' 3 ...caught at -e line 1. then we shouldn’t get this: $ ./perl -Ilib -e '$@ = 3; warn' Warning: something's wrong at -e line 1. as the two scalars hold the same value.
* Make warn handle magic vars (fixes [perl #97480])Father Chrysostomos2012-06-071-7/+16
| | | | | | | | | | | | | | | | | pp_warn was checking flags before calling get-magic, resulting in sev- eral bugs that I fixed all at once:: • warn now calls get-magic exactly once on its argument, when there is just one argument (it always worked correctly for multiple) [perl #97480]. • warn calls get-magic exactly once on $@ when falling back to it, instead of zero times. • A tied variable returning an object that stringifies as an empty string is no longer ignored if the tied variable was not ROK before FETCH. • A tied $@ containing a string, or $@ aliased to $1, is no longer ignored. • A tied $@ that last returned a reference but will return a string on the next FETCH now gets "\t...caught" appended.
* Use the same top format error for ""Father Chrysostomos2012-06-071-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | See also the previous commit. 2dd78f96 added the ‘Undefined top format called’ message for those cases where a GV doesn’t have a name. That was a bug that used to happen with *{$io}, which can’t happen any more. The code that 2dd78f96 added ended up changing a zero-length name to be treated the same way as no name. It also checked the length by cheating and checking the first character instead. Now that we have support for embedded nulls, that logic ends up wrong for names like "\0foo". And there is no need to treat "" differently from "foo" anyway. So this patch restores things the way they were before 2dd78f96. It also improves the tests for ‘Undefined format’. Writing tests for ‘Undefined top format’ was quite painful, as that error seems to leave the internal state out of synch. I suspect PL_formtarget needs to be localised, or the error just needs to come earlier in pp_leavewrite. But I’ll save that for later, or for Dave Mitchell. :-)
* Get rid of ‘Not a format reference’Father Chrysostomos2012-06-071-7/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit: commit 2dd78f96d61cc6382dc72214930c993567209597 Author: Jarkko Hietaniemi <jhi@iki.fi> Date: Sun Aug 6 01:33:55 2000 +0000 Continue fixing the io warnings. This also sort of fixes bug ID 20000802.003: the core dump is no more. Whether the current behaviour is correct (giving a warning: "Not a format reference"), is another matter. p4raw-id: //depot/perl@6531 added a check to see whether the format GV’s name is null, and, if so, it dies with ‘Not a format reference’. Before that, that message occurred only for lack of a GV. The bug mentioned is now #3617, involving write(*STDOUT{IO}). write puts an implicit *{} around its argument. *{$io} has historically been very buggy in its stringification, so this patch seems to have been working around that bugginess, by fall- ing back to the ‘Not a format reference’ error if the name couldn’t be determined for ‘Undefined format "foo" called’. *{$io} was fixed once and for all in 5.16. It now stringifies as *foopackage::__ANONIO__. I don’t think producing a completetly different error based on the name of the GV (whether it’s "foo" or "") is correct at all. And the patch that made it happen was just a fix for a crash that can’t hap- pen any more. So the only case that should produce ‘Not a format reference’ is that in which there is no format GV (fgv). I can prove that fgv is always set (see below), and has been at least since 5.000, so that ‘Not a format reference’ actually could never occur before 2dd78f96d61c. (Actually, XS code could set PL_defoutgv to null until the previous commit, but everything would start crashing as a result, so it has never been done in practice.) gv_efullname4 always returns a name, so checking SvPOK(tmpsv) is redundant; checking whether the string buffer begins with a non-null char is not even correct, as "\0foo" fails that test. Proof that fgv is always set: The current (prior to this commit) code in pp_enterwrite is like this: if (MAXARG == 0) { gv = PL_defoutgv; EXTEND(SP, 1); } else { gv = MUTABLE_GV(POPs); if (!gv) gv = PL_defoutgv; } If the stack value is null (which actually can’t happen), PL_defoutgv is used. PL_defoutgv can’t be null. At this point, gv is set to something non-null. io = GvIO(gv); if (!io) { RETPUSHNO; } Here we only set fgv to IoFMT_GV(io) if it is non-null. Otherwise we use gv, which we know is non-null. if (IoFMT_GV(io)) fgv = IoFMT_GV(io); else fgv = gv;
* Make setdefout accept only NNFather Chrysostomos2012-06-071-1/+2
| | | | | | | | | Just search through the source for GvIOp(PL_defoutgv) and you will see that perl assumes that PL_defoutgv is never null. I tried setting it to null from XS and got crashes, unsurprisingly. The only CPAN user of PL_defoutgv sets it to STDOUT.
* 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.
* Block signals during fork (fixes RT#82580)Leon Timmermans2012-05-251-0/+21
|
* Fix non-GCC compilationFather Chrysostomos2012-05-211-2/+2
| | | | I mistakenly thought XPUSHs(...) was an expression. Now it is.
* pp_sys.c:S_try_amagic_ftest: Remove SPAGAINFather Chrysostomos2012-05-211-2/+0
| | | | Overloading pushes a new stack to prevent the need for this.
* pp_sys.c: Remove SPAGAIN after my_(l)stat_flagsFather Chrysostomos2012-05-211-4/+0
| | | | | As of the previous commit, these two functions no longer affect the stack.
* Move stack extension into FT_* macrosFather Chrysostomos2012-05-211-7/+3
| | | | | | | | 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 -t BAREWORD extend the stackFather Chrysostomos2012-05-211-0/+1
| | | | | It appears always to have been this way. It was writing past the end of the stack.
* Make filetest ops fiddle the stack lessFather Chrysostomos2012-05-211-27/+17
| | | | | | | | | | | 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.
* [perl #111864] Don’t leave obj on stack for -x $overloadedFather Chrysostomos2012-03-281-2/+6
| | | | | | | | | | | | | | | | | | | | | | Commit 8db8f6b697e changed the way filetest operators use the stack, in order to make stacked -t work. Filetest operators were changed to pop the argument off the stack for a standalone operator, but to leave it on the stack for a stacking op (so the next operator could use it). The code for handling overloaded objects, which was separate, was already doing something similar, by not popping the object off the stack. I made the mistake of changing overloaded objects’ return code to share code with regular filetest operators (the FT_RETURN_* macros), but without changing the way the overload code got the item from the stack to begin with. Hence, the returning code assumed that the argu- ment had been popped for non-stacking ops, which was not the case. This commit changes the way the overload case does it’s return, to account for the fact that the object must be left on the stack when initially fetched from it (in case the object turns out not to have -X overloading and the regular code has to kick in).
* [rt #111654] properly propgate tainted errorsTony Cook2012-03-121-1/+1
| | | | | | | | | A magic value (such as a tainted string) may not have POK set, so call SvPV() to find out if there's something in ERRSV to report. Possibly this should be using SvPV_nomg(), but this is the first request for magic in this code. Maybe the code above should be calling SvGETMAGIC() before checking SvROK().
* Remove gete?[ug]id cachingÆvar Arnfjörð Bjarmason2012-02-181-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* prune faulty dead logic in pp_flockZefram2012-02-171-1/+1
| | | | | | | pp_flock had code to implicitly use the "last read" I/O handle if invoked with no arguments. Actually both of its arguments are mandatory, so this could never be reached. It was presumably cargo-culted from another op such as pp_tell.
* Further eliminate POSIX-emulation under LinuxThreadsÆvar Arnfjörð Bjarmason2012-02-151-10/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Under POSIX threads the getpid() and getppid() functions return the same values across multiple threads, i.e. threads don't have their own PID's. This is not the case under the obsolete LinuxThreads where each thread has a different PID, so getpid() and getppid() will return different values across threads. Ever since the first perl 5.0 we've returned POSIX-consistent semantics for $$, until v5.14.0-251-g0e21945 when the getpid() cache was removed. In 5.8.1 Rafael added further explicit POSIX emulation in perl-5.8.0-133-g4d76a34 [1] by explicitly caching getppid(), so that multiple threads would always return the same value. I don't think all this effort to emulate POSIX sematics is worth it. I think $$ and getppid() are OS-level functions that should always return the same as their C equivalents. I shouldn't have to use a module like Linux::Pid to get the OS version of the return values. This is pretty much a complete non-issue in practice these days, LinuxThreads was a Linux 2.4 thread implementation that nobody maintains anymore[2], all modern Linux distros use NPTL threads which don't suffer from this discrepancy. Debian GNU/kFreeBSD does use LinuxThreads in the 6.0 release, but they too will be moving away from it in future releases, and really, nobody uses Debian GNU/kFreeBSD anyway. This caching makes it unnecessarily tedious to fork an embedded Perl interpreter. When someone that constructs an embedded perl interpreter and forks their application, the fork(2) system call isn't going to run Perl_pp_fork(), and thus the return value of $$ and getppid() doesn't reflect the current process. See [3] for a bug in uWSGI related to this, and Perl::AfterFork on the CPAN for XS code that you need to run after forking a PerlInterpreter unbeknownst to perl. We've already been failing the tests in t/op/getpid.t on these Linux systems that nobody apparently uses, the Debian GNU/kFreeBSD users did notice and filed #96270, this patch fixes that failure by changing the tests to test for different behavior under LinuxThreads, I've tested that this works on my Debian GNU/kFreeBSD 6.0.4 virtual machine. If this change is found to be unacceptable (i.e. we want to continue to emulate POSIX thread semantics for the sake of LinuxThreads) we also need to revert v5.14.0-251-g0e21945, because currently we're only emulating POSIX semantics for getppid(), not getpid(). But I don't think we should do that, both v5.14.0-251-g0e21945 and this commit are awesome. This commit includes a change to embedvar.h made by "make regen_headers". 1. http://www.nntp.perl.org/group/perl.perl5.porters/2002/08/msg64603.html 2. http://pauillac.inria.fr/~xleroy/linuxthreads/ 3. http://projects.unbit.it/uwsgi/ticket/85
* 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.
View Lorry Controller Status