summaryrefslogtreecommitdiff
path: root/perl.c
Commit message (Collapse)AuthorAgeFilesLines
* SITELIB_EXP may be NULL on WindowsJan Dubois2012-04-161-11/+13
| | | | | | | The sitelib directory is located dynamically at runtime by checking for the ../site path relative to the location of perl5xx.dll. This directory doesn't exist at buildtime, so calling strlen(NULL) may cause an access violation...
* Avoid 'USE_SITECUSTOMIZE redefined'-warning during compilationGisle Aas2012-03-271-1/+1
|
* In S_parse_body(), don't "leak" linestr_sv until global destruction.Nicholas Clark2012-03-171-4/+6
| | | | | | | | | | | | | | | | This commit ensures that linestr_sv is properly cleaned up, if allocated. The local variable linestr_sv was added by commit 009d90df4e17a415 in 2007, to replace use of PL_linestr in S_parse_body(). However, that commit didn't add any code to free linestr_sv at the end of S_parse_body(), meaning that the SV sticks around until global destruction. Subsequent code simplification possible by the removal of suidperl reveals that linestr_sv is only needed for the '-x' option, so it's safe to avoid allocating it up front. Additionally, during '-x' processing, Perl_sv_gets() will upgrade the target SV to SVt_PV and allocate the string buffer as needed, so there's no need to pre-upgrade or pre-allocate the SV in S_parse_body(). This slightly reduces the amount of code.
* Remove all the never used parameters from the macro validate_suid()Nicholas Clark2012-03-171-6/+3
| | | | | | Several parameters are unused in either remaining variant of the validate_suid() macro. The two variants which used the extra parameters were removed with suidperl by commit cc69b689ee7c2745 in Jan 2009.
* The parser should always close the file handle that it opened.Nicholas Clark2012-02-271-1/+3
| | | | | | | | | | | | | | | | | Previously it would leave the file handle open if it was (equal to) stdin, on the assumption that this must have been because no script name was supplied on the interpreter command line, so the interpreter was defaulting to reading the script from standard input. However, if the program has closed STDIN, then the next file handle opened (for any reason) will have file descriptor 0. So in this situation, the handle that require opened to read the module would be mistaken for the above situation and left open. Effectively, this leaked a file handle. This is now fixed, by explicitly tracking from parser creation time whether it should keep the file handle open, and only setting this flag when defaulting to reading the main program from standard input. This resolves RT #37033.
* Move the close-on-exec logic to one place, at the end of S_open_script().Nicholas Clark2012-02-271-10/+4
| | | | | | Now that the logic for stdin is implemented as an early return of NULL from S_open_script(), in all cases that reach the end of S_open_script(), rsfp is non-NULL, and a file handle that we wish to set to close on exec.
* Change S_open_script() to return NULL to signal "read from stdin".Nicholas Clark2012-02-271-1/+4
| | | | | Move the logic to assign PerlIO_stdin() to rsfp from S_open_script() to its only caller, S_parse_body().
* In perl.c, change S_open_script() to return rsfp.Nicholas Clark2012-02-271-13/+13
| | | | | | Previously it was being passed &rsfp as a parameter, because it was returning another value, fdscript. However, the return value has been ignored since commit cc69b689ee7c2745 removed suidperl in January 2009.
* In S_validate_suid(), move declarations after the first statement.Nicholas Clark2012-02-191-2/+2
| | | | | Otherwise exacting C89 compilers refuse to build the code. And at least one Win32 compiler is exacting on this.
* Remove gete?[ug]id cachingÆvar Arnfjörð Bjarmason2012-02-181-16/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Further eliminate POSIX-emulation under LinuxThreadsÆvar Arnfjörð Bjarmason2012-02-151-3/+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
* add wrap_op_checker() API functionZefram2012-02-111-0/+1
| | | | | This function provides a convenient and thread-safe way for modules to hook op checking.
* Add PERL_RELOCATABLE_INCPUSH to PL_non_bincompat_options, and hence -V output.Nicholas Clark2012-02-081-0/+3
| | | | | | | | PERL_RELOCATABLE_INCPUSH was added in commit f31c6eed22759301. As it causes a small specific behaviour change that isn't visible in any other configuration option, it seems useful to indicate that the perl binary has been compiled with it, to aid debugging. (Specifically, debugging of "Why isn't this working?" when it failed to be enabled.)
* [perl #108794] Call special blocks in void contextFather Chrysostomos2012-01-221-1/+1
| | | | | Now BEGIN blocks, etc., are called in void context, so the result of evaluating the last statement is not wastefully copied.
* Bump several file copyright datesSteffen Schwigon2012-01-191-1/+1
| | | | | | | Sync copyright dates with actual changes according to git history. [Plus run regen_perly.h to update the SHA-256 checksums, and regen/regcharclass.pl to update regcharclass.h]
* Bump the visible perl -V copyright to 2012Steffen Schwigon2012-01-191-1/+1
|
* Provide as much diagnostic information as possible in "panic: ..." messages.Nicholas Clark2012-01-161-2/+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.
* Suppress confusing uninit warning from -T _Father Chrysostomos2012-01-131-1/+1
| | | | | | | | | | | -T _ uses the file name saved by a preceding stat. If there was no preceding stat, the internal sv used to store the file name is unde- fined, so SvPV producing an uninitialized warning. Normally a failed -T will just return undefined and set $!. Normally stat on a filehan- dle will set the internal stat file name to "". This commit sets the internal file name to "" initially on startup, instead of creating an undefined scalar.
* 'S' case already exists with ALTERNATE_SHEBANG.Craig A. Berry2011-12-311-1/+5
| | | | Follow-up to b7e077d0225eac833ce2eb6fe9e1807f77d0f848.
* [perl #104288] Die with ‘Unrecognized switch’ on #! lineFather Chrysostomos2011-12-301-1/+5
| | | | | | | | | | | | | | | | | If a switch such as -x that cannot occur on the shebang line is used there, perl dies with ‘Can’t emulate...’. If an unrecognised switch is used on the command line, perl dies with ‘Unrecognized switch...’. It just happens to use the former error message for unrecognized switches on the shebang line, which can be confusing: $ perl -e '#!perl -G' Can't emulate -G on #! line at -e line 1. This commit changes it to output the same message as command-line switches for those that are unrecognised wherever they are used.
* Croak when setting a tied @DB::argsFather Chrysostomos2011-12-281-1/+1
| | | | | | | | In commit f8c105437 I stopped the setting of a tied @DB::args from crashing, by untying the array. Untying an array automatically with- out saying anything seems a little too much like action at a distance. For now, let’s just croak, as we can always change it later once we decide what should happen. At least that’s better than crashing.
* Fix compiler warning in perl.cFather Chrysostomos2011-12-271-1/+1
|
* Don’t check for tied @DB'args when not REALFather Chrysostomos2011-12-271-2/+2
| | | | | | This should make things just a smidgen faster in the most common case. As of the previous commit, tied arrays are always AvREAL.
* Fix crash when tying @DB::argsFather Chrysostomos2011-12-271-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | I was looking at diag.t to see what messages I could document. ‘av_reify called on tied array’ looked interesting, so I decided to see whether I could trigger it. I got something else: ./perl -Ilib -lwe ' sub TIEARRAY{bless[]} sub CLEAR{} sub EXTEND{} tie @DB::args, ""; package DB; sub {() = caller 0;}->(1,2,3); ' Name "DB::args" used only once: possible typo at -e line 5. Bus error How exciting! What’s happening is that Perl_init_dbargs turns off AvREAL after clearing a real array. Then pp_caller does av_extend and merrily tries to copy into AvARRAY(PL_dbargs). But AvARRAY has not been allo- cated, because av_extend called EXTEND instead. I fixed this by untying the array before turning off AvREAL. I don’t know whether that is the best fix. Alternatives would be to croak or to do the assignment in pp_caller differently for tied arrays (in which case tying @DB::args would cause objects to leak unexpectedly, until the next caller() call in the DB package).
* Remove explicit support for pre-7.0 VMS and pre-6.0 DEC C.Craig A. Berry2011-12-101-3/+0
| | | | | | | | | | | | | | | | | | | OpenVMS v7.0 was released in 1995. There have been no reports of recent releases of Perl building on versions that far back, yet we still have quite a bit of code that explicitly supports versions *prior* to v7.0. There is a similar story for DEC C v6.0. It was released in 1998, and has been superceded by numerous subsequent versions. Yet the VMS-specific code in the core is littered with workarounds and hacks that defend against deficiencies in very old compiler versions. This code is for all practical purposes no longer maintained or maintainable, so the best path forward seems to be to remove it. Anyone able and willing to commit to long-term support of it could argue for its restoration, assuming Perl 5.14.x is not adequate.
* Simplify S_parse_body() by calling S_usage() and S_minus_v() directly.Nicholas Clark2011-12-041-9/+6
| | | | | | | | | | Previously the code for "--help" and "--version" set a local variable to a string corresponding to the single character option ("h" or "v" respectively), then restarted the option parsing code, which would then call into Perl_moreswitches(), which would then use a switch statement to dispatch to the final code. This is not as clear as it could be.
* Break the -v code out from Perl_moreswitches() into S_minus_v().Nicholas Clark2011-12-041-43/+50
|
* Refactor S_usage() to take 0 parameters and exit directly().Nicholas Clark2011-12-041-6/+4
| | | | | This simplifies the code, as it's only called from one spot, in Perl_moreswitches().
* Remove the VMS-specific private len in S_mayberelocate.Craig A. Berry2011-12-031-2/+1
| | | | | | | | | | | | | This particular C<STRLEN len;> came along almost 15 years ago, way back in aa6893958c2b. Back then it was a plain and simple block scope variable. But now this code lives in a function that takes as an argument a variable of the same name and having the same meaning (i.e., the length of the directory name to be added to @INC). Someone looking only at the argument list might reasonably expect to be able to use len (though luckily there are no subsequent uses of it currently). So we really ought to update that len rather than create our own when we hijack the directory name to make our unixified version of it.
* VMS-specific scope fix for S_mayberelocate.Craig A. Berry2011-12-031-0/+2
| | | | | | | | | | | | | Back in 3185893b8dec106 I moved some code from the beginning of one block to the middle of a different block. Bad me. The compiler has been lax about allowing declarations in the middle of a block, so we haven't noticed. But as of c29067d7797853039, the code moved to a new function while leaving the block it was in behind and we end up with conflicting declarations of len. Making our own block seems like the safest thing to do. The indentation in this section of code is a bit wacky -- I chose the least intrusive alternative for clearer blame logs.
* Small tidyups in S_incpush() and S_mayberelocate()Nicholas Clark2011-12-031-8/+2
| | | | | | | | Following commit 816005240f1a3b99, which moved VMS-specific code, we can now assign to subdir at the point of declaration. After the refactoring that moved code into S_mayberelocate(), we can assign to libdir at the point of declaration. In turn, this allows the merging of two #ifndef PERL_IS_MINIPERL blocks. Remove a blank line from S_mayberelocate().
* Avoid attacks on sitecustomize by using NUL delimiters to wrap filenames.Nicholas Clark2011-12-031-3/+9
| | | | | | | | | | | | Previously the generated code used regular '' strings, which meant that a crafted pathname containing ' characters could be used to inject code. Until the previous commit, this was only a problem if building in or Configuring to install to such a directory. Which, hopefully, would be "obviously wrong" to anyone capable of building Perl from source. However, fixing the bug that prevented sitecustomize being subject to relocatable include now means that for a relocatable pearl, an end-user controlled path can now reach the sitecusomize code.
* Make sitecustomize relocatableinc awareCarl Hayter2011-12-031-39/+62
| | | | | | | | | | When -Dusesitecustomize is used with -Duserelocatableinc, SITELIB_EXP/sitecustomize.pl is not found due to SITELIB_EXP having a '.../..' relocation path. This patch refactors the path relocation code from S_incpush() into S_mayberelocate() so that it can be used in both S_incpush() and in usesitecustomize's use of SITELIB_EXP.
* In Perl_moreswitches(), merge the cases for 't' and 'T'.Nicholas Clark2011-11-221-6/+2
| | | | | Both bodies were the same, aside from hardcoded 't' and 'T', which can be replaced with a variable.
* [perl #101486] Make PL_curstash refcountedFather Chrysostomos2011-10-221-9/+16
| | | | | | | | | | This stops PL_curstash from pointing to a freed-and-reused scalar in cases like ‘package Foo; BEGIN {*Foo:: = *Bar::}’. In such cases, another BEGIN block, or any subroutine definition, would cause a crash. Now it just happily proceeds. newATTRSUB and newXS have been modified not to call mro_method_changed_in in such cases, as it doesn’t make sense.
* Remove unused variable from S_set_caret_XFather Chrysostomos2011-10-021-1/+0
|
* Don't use swash to find cntrlsKarl Williamson2011-10-011-2/+0
| | | | | | | | | Unicode stability policy guarantees that no code points will ever be added to the control characters beyond those already in it. All such characters are in the Latin1 range, and so the Perl core already knows which ones those are, and so there is no need to go out to disk and create a swash for these.
* No need for swashes for computing if ASCIIKarl Williamson2011-10-011-2/+0
| | | | | This information is trivially computed via the macro, no need to go out to disk and store a swash for this.
* Where available, use _NSGetExecutablePath() to make $^X absolute.Nicholas Clark2011-09-271-0/+24
| | | | | | | | | In Configure, check whether _NSGetExecutablePath() can be used to find the absolute pathname of the executable. If so, set usensgetexecutablepath in config.sh and USE_NSGETEXECUTABLEPATH in config.h. If this is set, then use this approach in S_set_caret_X() to canonicalise $^X as an absolute path. This approach works on OS X, and possible on other platforms that use dyld.
* Where available, use sysctl() with KERN_PROC_PATHNAME to make $^X absolute.Nicholas Clark2011-09-271-1/+25
| | | | | | | | | | In Configure, check whether sysctl() and KERN_PROC_PATHNAME can be used to find the absolute pathname of the executable. If so, set usekernprocpathname in config.sh and USE_KERN_PROC_PATHNAME in config.h. If this is set, then use this approach in S_set_caret_X() to canonicalise $^X as an absolute path. This approach works on (at least) FreeBSD, and doesn't rely on the /proc filesystem existing, or /proc/curproc/file being present.
* Don't #include headers already included by perl.hNicholas Clark2011-09-151-8/+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
* Simplify S_set_caret_X() by returning early if we set caret_x.Nicholas Clark2011-09-141-9/+7
| | | | This avoids duplicating the fallback code to set caret_x to PL_origargv[0].
* Inline S_procself_val() into S_set_caret_x().Nicholas Clark2011-09-141-36/+25
| | | | | | | | Possibly this should have been done as part of commit 3aa90d208c3bbfc1, which broke S_set_caret_X() out from S_init_postdump_symbols(). [S_procself_val() was not inlined into S_init_postdump_symbols() because Nick Ing-Simmons thought it unwise to hold on to MAXPATHLEN bytes of stack longer than necessary.]
* In S_set_caret_X(), use GvSV() consistently in all conditional code.Nicholas Clark2011-09-131-3/+4
| | | | | | | Commit c69033f2a6291605 was inconsistent, in that it changed two instances of GvSV() to GvSVn(), but not the third. The expansion of GvSV() is simpler, and is appropriate here. Hoist the call to GvSV() out of the conditional code.
* Add HOMEGROWN_POSIX_SIGNALS to PL_non_bincompat_options, and hence -V output.Nicholas Clark2011-09-101-0/+3
| | | | HOMEGROWN_POSIX_SIGNALS is only relevant on VMS.
* Convert some files from Latin-1 to UTF-8Keith Thompson2011-09-071-1/+1
|
* SVTYPEMASK must be cast to (svtype) when comparing to SvTYPE()Chip Salzenberg2011-08-231-1/+1
|
* [perl #97020] Carp (actually caller) leaking memoryFather Chrysostomos2011-08-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit eff7e72c3 (Detect incomplete caller overrides in Carp) used this little trick for detecting a @DB::args that an overridden caller() failed to set: + @args = \$i; # A sentinal, which no-one else has the address of But there is a bug in caller(). The first time caller tries to write to @DB::args, it calls Perl_init_dbargs first. That function checks whether @DB::args is AvREAL, in case someone has assigned to it, and takes appropriate measures. But caller doesn’t bother calling Perl_init_dbargs more than once. So manually-assigned items in @DB::args would leak, starting with the *second* call to caller. Commit eff7e72c3 triggered that bug, resulting in a regression in Carp, in that it started leaking. eff7e72c3 was backported to 5.12.2 with commit 97705941a4, so in both 5.12 and 5.14 Carp is affected. This bug (the caller bug, not Carp’s triggering thereof) also affects any caller overrides that set @DB::args themselves, if there are alternate calls to the overridden caller and CORE::caller. This commit fixes that by changing the if (!PL_dbargs) condition in pp_caller to if (!PL_dbargs || AvREAL(PL_dbargs)). I.e., if @args is either uninitialised or AvREAL then call Perl_init_dbargs. Perl_init_dbargs also has a bug in it, that this fixes: The array not only needs AvREAL turned off, but also AvREIFY turned on, so that assignments to it that occur after its initialisation turn AvREAL back on again. (In fact, Larry Wall added a comment suggesting this back in perl 5.000.)
* Simplify embedvar.h, removing a level of macro indirection for PL_* variables.Nicholas Clark2011-08-111-10/+10
| | | | | | | For the default (non-multiplicity) configuration, PERLVAR*() macros now directly expand their arguments to tokens such as C<PL_defgv>, instead of expanding to C<PL_Idefgv>. This removes over 350 lines from F<embedvar.h>, which defined macros to map from C<PL_Idefgv> to C<PL_defgv> and so forth.
* Add UNLINK_ALL_VERSIONS to PL_non_bincompat_options, and hence -V output.Nicholas Clark2011-07-241-0/+3
| | | | UNLINK_ALL_VERSIONS only makes sense for VMS.
View Lorry Controller Status