summaryrefslogtreecommitdiff
path: root/util.c
Commit message (Collapse)AuthorAgeFilesLines
* [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.
* Simplify embedvar.h, removing a level of macro indirection for PL_* variables.Nicholas Clark2011-08-111-4/+4
| | | | | | | 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.
* Revise check for negative versions plus testJohn Peacock2011-07-011-3/+5
|
* For shorter strings, store C<study>'s data as U8s or U16s, instead of U32s.Nicholas Clark2011-07-011-16/+69
| | | | | | | The assumption is that most studied strings are fairly short, hence the pain of the extra code is worth it, given the memory savings. 80 character string, 336 bytes as U8, down from 1344 as U32 800 character string, 2112 bytes as U16, down from 4224 as U32
* Store C<study>'s data as U32s, instead of I32s.Nicholas Clark2011-07-011-10/+11
| | | | The "no more" condition is now represented as ~0, instead of -1.
* Tidy code in pp_study and Perl_screaminstr()Nicholas Clark2011-07-011-7/+7
| | | | | | | | | In pp_study eliminate the variable pos, which duplicates len. ch should be U8, not I32. In Perl_screaminstr(), move the declarations of s and x to their point of use, convert a for loop to a while loop, and avoid incrementing and decrementing s. found is a boolean.
* Store C<study>'s data in in mg_ptr instead of interpreter variables.Nicholas Clark2011-07-011-2/+10
| | | | | This allows more than one C<study> to be active at the same time. It eliminates PL_screamfirst, PL_lastscream, PL_maxscream.
* Merge PL_scream{first,next} into one allocated buffer.Nicholas Clark2011-07-011-3/+4
| | | | | Effectively, PL_screamnext is now PL_screamfirst + 256. The actual interpreter variable PL_screamnext is eliminated.
* Change PL_screamnext to store absolute positions.Nicholas Clark2011-07-011-16/+18
| | | | | | | | | | PL_screamnext gives the position of the next occurrence of the current octet. Previously it stored this as an offset from the current position, with -pos stored for "no more", so that the calculated new offset would be zero, allowing a zero/non-zero loop exit test in Perl_screaminstr(). Now it stores absolute position, with -1 for "no more". Also codify -1 as the "not present" value for PL_screamfirst, instead of any negative value.
* Report a better error when trying to use negative version numbers instead of ↵Claes Jakobsson2011-06-301-0/+3
| | | | 'Invalid version format (non-numeric data)' as it currently does. Also update documentation that version should be a positive number.
* Move PL_{No,Yes,hexdigit} from perlvars.h to perl.h, as all are const char[]Nicholas Clark2011-06-121-3/+0
| | | | | | | | | | | They were converted in perl.h from const char[] to #define in 31fb120917c4f65d, then re-instated as const char[], but in perlvars.h, in 3fe35a814d0a98f4. There's no need for compile-time constants to jump through the hoops of perlvars.h, even for Symbian, as the various "EXTCONST" variables already in perl.h demonstrate. These were the only 3 users of the the PERLVARISC macro, so eliminate that, and all related code.
* Refactor Perl_get_vtbl() to a small array lookup from a large switch statement.Nicholas Clark2011-06-111-95/+2
| | | | Provide magic_vtable_max, the number of elements in PL_magic_vtables[].
* Abolish PL_vtbl_sig. It's been all 0s since it was added in 5.0 alpha 2.Nicholas Clark2011-06-111-3/+0
| | | | | Magic with a NULL vtable is equivalent to magic with a vtable of all 0s. On CPAN, only Apache::Peek's code for 5.005 is referencing it.
* Don't even declare PL_vtbl_sigelem under -DPERL_MICRONicholas Clark2011-06-111-0/+2
| | | | This turns out to be a simpler solution than 9ba75e3cf905a6e6.
* Store FBMs in PVMGs, instead of GVs.Nicholas Clark2011-06-111-2/+2
| | | | | | | | This should reduce the complexity of code dealing with GVs, as they no longer try to play several different incompatible roles. (As suggested by Ben Morrow. However, it didn't turn out to be as straightforward as one might have hoped).
* Store the BM table in mg_ptr instead of after SvCUR().Nicholas Clark2011-06-111-11/+28
| | | | | | | | | | | | Previously the 256 byte Boyer-Moore table was stored in the buffer of SvPVX() after the raw string by extending the buffer. Given that the scalar is alway upgraded to add PERL_MAGIC_bm magic, to clear the table and other flags, there's no extra memory cost in using mg_ptr in the MAGIC struct to point directly to the table. I believe that this removes the last place in the core that stores data beyond SvCUR().
* Exit early from Perl_fbm_compile() if the SV is already "compiled".Nicholas Clark2011-06-111-0/+3
| | | | | I believe that this can only happen if a constant subroutine is used more than once as the second argument to index.
* In Perl_fbm_instr(), use a switch() statement for the special case code.Nicholas Clark2011-06-111-8/+10
| | | | | Previously the special-case code for lengths 0, 1 and 2 was in a nested set of if() statements, which was slightly cryptic to read.
* In Perl_fbm_compile(), use STRLEN instead of U32 to calculate BmPREVIOUS().Nicholas Clark2011-06-111-4/+4
| | | | | | | | | This should fix a theoretical bug on strings longer than 2**32 bytes where the byte referenced by BmRARE() is at an offset beyond 2**32. I'm not sure how to test this, as I think to trigger it one would need to have one of a: the second argument to index as a string literal, longer than 2**32 bytes b: a fixed string in a regex, longer than 2**32 bytes
* Use SvTAIL() instead of BmFLAGS(). The core no longer uses BmFLAGS().Nicholas Clark2011-06-111-1/+1
|
* Emulate the value of BmFLAGS() using SvTAIL().Nicholas Clark2011-06-111-1/+0
| | | | | | | | | | | | | | | | | | | | Don't set BmFLAGS() in Perl_fbm_compile() Originally fbm_compile() had an I32 flags argument, which seems to have been part of case folding/locale improvements. bbce6d69784bf43b removed this. SvTAIL() was only used in once place until c277df42229d99fe. 2779dcf1a3ceec16 added the U32 flags argument to fbm_compile(), not used until cf93c79d660ae36c. That commit also added FBMcf_TAIL and FBMcf_TAIL{z,Z,DOLLAR} but didn't use the last three. Additionally, it stored the BmFLAGS as part of the compiled table: + table[-1] = flags; /* Not used yet */ f722798beaa43749 added FBMcf_TAIL_DOLLARM, renumbered FBMcf_TAIL{z,Z,DOLLAR}, but still didn't use anything other than FBMcf_TAIL. The core, nothing on CPAN, and nothing visible to Google codesearch, has ever used the 4 specialist flags. The only use is 0 or FBMcf_TAIL, which is in lockstep with SvTAIL() of 0 or non-0.
View Lorry Controller Status