summaryrefslogtreecommitdiff
path: root/util.c
Commit message (Collapse)AuthorAgeFilesLines
* Remove the VM/ESA port.Nicholas Clark2012-08-311-3/+3
| | | | | VM/ESA was a mainframe OS. IBM ended service on it in June 2003. It was superseded by Z/VM.
* Omnibus removal of register declarationsKarl Williamson2012-08-181-55/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Remove the UTS port.Nicholas Clark2012-08-171-3/+0
| | | | | | UTS was a mainframe version of System V created by Amdahl, subsequently sold to UTS Global. The port has not been touched since before 5.8.0, and UTS Global is now defunct.
* Remove dead code related to the Atari ST port of perl 4.0 patchlevel 19Nicholas Clark2012-07-281-10/+7
| | | | | The subdirectory containing the port specific files was purged when 5.000 was released, but changes made to other files were not removed.
* rt #72232 - ignore wday/yday in mini_mktime as indirectly documentedTony Cook2012-07-051-12/+2
|
* Use assertions for /* NOT REACHED */Father Chrysostomos2012-06-151-6/+6
| | | | to make sure it really is never reached.
* util.c:report_evil_fh: Report name w/initial nullFather Chrysostomos2012-06-071-1/+1
| | | | | In the error message, we shouldn’t omit a handle whose name begins with "\0", but, rather, a handle whose name has no length to it.
* util.c:report_evil_fh: Rmv redundant SvPOKFather Chrysostomos2012-06-071-1/+1
| | | | newSVhek (used to create this SV) always returns an SvPOK scalar.
* util.c:report_wrongway_fh: Report name w/initial nullFather Chrysostomos2012-06-071-1/+1
| | | | | In the error message, we shouldn’t omit a handle whose name begins with "\0", but, rather, a handle whose name has no length to it.
* util.c:report_evil_fh: Rmv redundant isGV checkFather Chrysostomos2012-06-071-1/+1
| | | | | | | Checking isGV_with_GP makes the isGV check redundant. The only case in which isGV could be true when isGV_with_GP is false could be a GV playing PVBM, but those don’t exist any more. When they did exist, this check was probably wrong (and crashable).
* util.c:report_wrongway_fh: Don’t create an SVFather Chrysostomos2012-06-071-4/+4
| | | | | Now that sv_vcatpvfn supports HEKs directly, we don’t need to create a temporary SV out of one.
* util.c:report_wrongway_fh: Rmv redundant isGV checkFather Chrysostomos2012-06-071-1/+1
| | | | | | | Checking isGV_with_GP makes the isGV check redundant. The only case in which isGV could be true when isGV_with_GP is false could be a GV playing PVBM, but those don’t exist any more. When they did exist, this check was probably wrong (and crashable).
* Assertion failure with $/=*foo; warn;Father Chrysostomos2012-06-071-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | $ ./perl -Ilib -e '$/=*foo; <>; warn' <./perl Assertion failed: (!isGV_with_GP(_svcur)), function Perl_mess_sv, file util.c, line 1467. Abort trap The assertion happens when ‘<...> line 42’ is being appended to the message. The line of code in question is this: const bool line_mode = (RsSIMPLE(PL_rs) && SvCUR(PL_rs) == 1 && *SvPVX_const(PL_rs) == '\n'); It uses this macro in perl.h: #define RsSIMPLE(sv) (SvOK(sv) && (! SvPOK(sv) || SvCUR(sv))) which was last modified by commit af7d13df559: -#define RsSIMPLE(sv) (SvOK(sv) && SvCUR(sv)) -#define RsPARA(sv) (SvOK(sv) && ! SvCUR(sv)) +#define RsSIMPLE(sv) (SvOK(sv) && (! SvPOK(sv) || SvCUR(sv))) +#define RsPARA(sv) (SvPOK(sv) && ! SvCUR(sv)) So it looks as though it has always called SvCUR on something that is not necessarily a PV. As of commit af7d13df559, it has also called SvPVX on a potential non-PV. Fixing this simply involves using SvPV instead of SvPVX. I don’t know that t/io/open.t is the best place for the test, but all the other ‘<...> line 42’ tests are there.
* Do away with stashpv_hvname_matchFather Chrysostomos2012-06-041-10/+0
| | | | | | | | | | | | For some reason this is listed in the API, even though it is not docu- mented and is only available under ithreads. It was added by commit ed221c5717, which doesn’t explain why it needed to be part of the API. (Presumably because a public macro used it, even though there are better ways to solve that.) It is unused on CPAN and (now) in core, so there is no reason to keep it.
* [perl #78742] Store CopSTASH in a pad under threadsFather Chrysostomos2012-06-041-25/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before this commit, a pointer to the cop’s stash was stored in cop->cop_stash under non-threaded perls, and the name and name length were stored in cop->cop_stashpv and cop->cop_stashlen under ithreads. Consequently, eval "__PACKAGE__" would end up returning the wrong package name under threads if the current package had been assigned over. This commit changes the way cops store their stash under threads. Now it is an offset (cop->cop_stashoff) into the new PL_stashpad array (just a mallocked block), which holds pointers to all stashes that have code compiled in them. I didn’t use the lexical pads, because CopSTASH(cop) won’t work unless PL_curpad is holding the right pad. And things start to get very hairy in pp_caller, since the correct pad isn’t anywhere easily accessible on the context stack (oldcomppad actually referring to the current comppad). The approach I’ve followed uses far less code, too. In addition to fixing the bug, this also saves memory. Instead of allocating a separate PV for every single statement (to hold the stash name), now all lines of code in a package can share the same stashpad slot. So, on a 32-bit OS X, that’s 16 bytes less memory per COP for short package names. Since stashoff is the same size as stashpv, there is no difference there. Each package now needs just 4 bytes in the stashpad for storing a pointer. For speed’s sake PL_stashpadix stores the index of the last-used stashpad offset. So only when switching packages is there a linear search through the stashpad.
* Use isGV_with_GP in util.c:fbm_compileFather Chrysostomos2012-05-291-5/+1
| | | | | | | | | | | | | This little statement: if (SvSCREAM(sv)) return; filters out not only studied strings, but also GVs. Since studied strings are gone, it only filters out GVs now. Since fbm_compile coerces its argument, we still want to filter out GVs, so we use isGV_with_GP to make the intent clear.
* Gut screaminstrFather Chrysostomos2012-05-291-163/+10
| | | | | | | | | | How did this ever end up in the API? Anyway, this commit guts it by removing its guts and replacing it with a panic message. This function would fail assertions if passed an unstudied scalar, so it should never be called any more. But XS mod- ules that still do if (SvSCREAM(sv)) screaminstr(...) should still be able to compile.
* Correct apidoc varnames for util.c:fbm_instrFather Chrysostomos2012-05-291-2/+2
|
* 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.
* [perl #112316] Make strict vars respect null-to-null assignmentFather Chrysostomos2012-04-201-1/+1
| | | | | | | | | | | | This is a follow-up to commits 6379d4a9a and 862504fb08. As Karl Williamson (thank you!) pointed out, my changes were not suf- ficient, because strEQ was still being used, which stops at the first null, treating "foo\0bar" and "foo\0foo" as equivalent. Under threads, strict vars was not respecting glob assignment from a package with a null in its name to another also with a null in its name, if the two package names shared a common prefix up to the null.
* Make strict vars respect ‘package ĵ; *ĵ::bar = [];’Father Chrysostomos2012-04-191-1/+1
| | | | | | | | | | In this particular case, the name of the current package in UTF-8 (it cannot be expressed in Latin-1) is the same byte sequence as the name of the package being assigned to in Latin-1. Some of the logic in stashpv_hvname_match was faulty. It worked for a Latin-1 current package assigning to a glob in a UTF-8 package, but not the other way around.
* [perl #112316] Make strict vars respect assignment from null pkgFather Chrysostomos2012-04-191-6/+8
| | | | | | Under threads, strict vars was not respecting glob assignment from a package with a null in its name if the name of the package assigned to was equal to the prefix of the current package up to the null.
* [perl #112316] Make strict vars respect assignment to null pkgFather Chrysostomos2012-04-191-1/+2
| | | | | | Under threads, strict vars was not respecting assignment to a package with a null in its name if the name of the package assigned from was equal to the prefix of the destination package up to the null.
* Don’t produce uninit warning for ->VERSION(9e99)Father Chrysostomos2012-04-171-1/+1
| | | | | | | | | This is a follow-up to commit 78e230aef16b. It was using a temporary undef scalar and concatenating to it instead of setting it, triggering the warning. I haven’t added tests, out of paranoia.
* [perl #112478] Avoid buffer overflow in upg_versionFather Chrysostomos2012-04-161-4/+14
| | | | | | | | | | | | | | On most systems, this is actually a panic, rather than an overflow, because the overflow is detected before it can happen. upg_version needs to use the equivalent of sprintf "%.9f" on a numeric input before parsing it. For speed’s sake, I assume, it was done using my_snprintf, with a C auto for the buffer, declared with a fixed size of 64. There is no guarantee that the number passed in will not overflow that buffer, so upg_version should use an SV and sv_catpvf in those cases where it would overflow.
* Stop warning hint-checking from doing bad readsFather Chrysostomos2012-03-071-1/+4
| | | | | | | | | | | | | | | | | | Setting ${^WARNING_BITS} should not allow perl to read past the end of a mallocked buffer. Previously the internal warning buffer would be copied straight from ${^WARNING_BITS}, so a short value assigned to that variable would cause the internal warning-checking code to read past the end of the buffer (probably not in actual practice, due to malloc’s rounding up, but theoretically). Now, the buffer that is allocated for storing the warning bits is padded with nulls to make it long enough to prevent bad reads. The stored length is still the same as what was assigned to ${^WARNING_BITS}, so that the value that comes out of it is the same length (UTF8-ness aside)--not that it makes much difference in prac- tice though, since only warnings.pm should care about this. This came up as part of perl #111500.
* 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
* sync version.pm code with CPANDavid Golden2012-02-051-1/+1
| | | | | | Applied patch from John Peacock, but added whitespace fixes, corrected pod link error and updated known Pod issues to reflect a fix.
* util.c: Add commentKarl Williamson2012-01-191-1/+2
|
* Provide as much diagnostic information as possible in "panic: ..." messages.Nicholas Clark2012-01-161-14/+25
| | | | | | | | | | | | | | | 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.
* Squash repetititive code in util.c:report_evil_fhFather Chrysostomos2012-01-131-17/+9
|
* util.c: Silence compiler warningKarl Williamson2012-01-131-0/+1
| | | | | cc on solaris is smart enough to figure out that this return isn't reached.
* diag_listed_as for -S errorFather Chrysostomos2011-12-281-0/+1
| | | | | | Also teach diag.t not to mistake /* die */ for a die() call, as it did in this case, consequently ignoring the diag_listed_as, which it thought was in the middle of the call.
* toke.c, util.c: setlocale returns new locale, not oldKarl Williamson2011-12-181-2/+6
| | | | | This means we have to call setlocale with a NULL second parameter to get the correct old value; then call it with the new value
* Use syntax from perlguts for testing objectsJohn Peacock2011-12-091-2/+2
| | | | | | | | | | | | | The following paragraph is in perlguts.pod: To check if you've got an object derived from a specific class you have to write: if (sv_isobject(sv) && sv_derived_from(sv, class)) { ... } which does the right thing with magical things like tied scalars. Signed-off-by: David Golden <dagolden@cpan.org>
* Use correct err msg in XS version checkFather Chrysostomos2011-11-241-1/+1
| | | | | | | | | | When an XS module’s version is checked when it is loading, the string "version" should be treated the same way as "versions" and emit the ‘Invalid version format’ error, instead of being treated as a version object at first and then rejected by the validator with the ‘Invalid version object’ error. See also perl #102586.
* [perl #102586] version->new("version") SEGVsFather Chrysostomos2011-11-221-1/+2
| | | | | | This adds an ROK check after calling sv_derived_from, as the latter also works for class names. It is done after sv_derived_from, rather than before, as sv_derived_from calls get-magic.
* Fix pp_goto crash with orphaned GVFather Chrysostomos2011-11-181-2/+5
| | | | | a7999c089 inadvertently made pp_goto crash if the GV had no stash pointer.
* util.c:get_db_sub: correct commentFather Chrysostomos2011-11-181-1/+2
| | | | | This comment was copied from pp_goto by commit 005a8a35, but was not adjusted to make sense in its new surroundings.
* Fix threaded buildFather Chrysostomos2011-11-181-1/+1
| | | | Commit a7999c0893, you are at fault!
* Make sure $DB::sub is callableFather Chrysostomos2011-11-181-4/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When DB::sub is about to be called (to handle a subroutine call under the debugger), $DB::sub is set to the name of the subroutine or a ref- erence to it. Sometimes $DB::sub is set to the name when the subroutine is not call- able under that name. That should not happen. This logic in util.c:Perl_get_db_sub decides whether a reference should be used: if ( svp && ((CvFLAGS(cv) & (CVf_ANON | CVf_CLONED)) || strEQ(GvNAME(gv), "END") || ((GvCV(gv) != cv) && /* Could be imported, and old sub redefined. */ !( (SvTYPE(*svp) == SVt_PVGV) && (GvCV((const GV *)*svp) == cv) && (gv = (GV *)*svp) ) ) )) { /* Use GV from the stack as a fallback. */ (That comment about using the GV from the stack as a fallback applies to the assignment to gv, but was mistakenly divorced from it in commit 3de9ffa12.) This logic (introduced in 71be2cbc7 [inseparable changes from perl5.003_13 to perl5.003_14] and integrated into blead in 491527d02) tries to find a GV that points to the CV, trying the CV’s own GV first, and falling back to what is on the stack. But it does not account for GVs that are not found under their names, which can hap- pen when a glob is copied and the original is undefined ($foo = *bar; undef *bar; &$foo) or when a stash element or package is deleted, such as via Symbol::delete_package. If the subroutine is not locatable under its own name or the name under which it was called (the name of the GV argument to entersub), then a reference should be passed. Otherwise a name that can access the sub should be passed. So this commit adds more (no, not more!) conditions to make sure the gv is actually reachable under its name before using a string. Since, for effiency, those conditions do not perform an actual symbol lookup, but simply look inside the GV’s stash, we can no longer rely on gv_efullname (or even gv_fullname), as the stash may have been moved around, but use HvENAME and construct the GV name ourselves.
* allow for 2Gb+ memory allocations on 64-bit Win32 debug buildsTony Cook2011-10-281-3/+3
| | | | | | | | | | | | | | | | | | long is 32-bit for the 64-bit Win32 memory model, so use the more portable SSize_t. Before the change: C:\Users\tony\dev\perl\git\perl>perl -e "open my $f, 'dir |' or die; $x = ''; re ad($f, $x, 4, 0x80000000)" panic: realloc at -e line 1. and after: C:\Users\tony\dev\perl\git\perl>perl -e "open my $f, 'dir |' or die; $x = ''; re ad($f, $x, 4, 0x80000000)" C:\Users\tony\dev\perl\git\perl>git add util.c
* don't segfault given string repeat count larger than 2^31Jim Meyering2011-10-231-4/+4
| | | | | | | | | | | E.g., this overflows INT_MAX and overruns heap memory: $ perl -le 'print "v"x(2**31+1)' [Exit 139 (SEGV)] (Perl_repeatcpy): Use the same type for "count" as our sole callers in pp.c: IV (long), not I32 (int). Otherwise, passing the wider value to a narrower "I32 count"
* Restore null checks to stashpv_hvname_match [perl #101430]Father Chrysostomos2011-10-161-0/+2
| | | | | | Commit aa33328e8 inadvertently removed the null checks from stashpv_hvname_match when adding UTF8 support, resulting in crashes it List::Gen’s test suite.
* util.c UTF8 cleanupBrian Fraser2011-10-061-12/+17
|
* util.c for threads: stashpv_hvname_match UTF8 cleanup.Brian Fraser2011-10-061-7/+16
|
* 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
* Convert some files from Latin-1 to UTF-8Keith Thompson2011-09-071-1/+1
|
* Eliminate global.sym, as makedef.pl can generate it internally.Nicholas Clark2011-08-251-1/+1
| | | | | | | | global.sym was a file listing the exported symbols, generated by regen/embed.pl from embed.fnc and regen/opcodes, which was only used by makedef.pl Move the code that generates global.sym from regen/embed.pl to makedef.pl, and thereby eliminate the need to ship a 907 line generated file.
View Lorry Controller Status