summaryrefslogtreecommitdiff
path: root/util.c
Commit message (Collapse)AuthorAgeFilesLines
* [perl #119169] index with __PACKAGE__ for 2nd argumentFather Chrysostomos2013-08-061-1/+1
| | | | | | | | | | | | | | | The refactoring of fbm_compile in 66379c06cd to prepare for c72a4eedff1 put in an SvIsCOW check before doing SvPV_force. I sim- ply changed the logic there so that SvPV_force would continue to have its effect but without tripping up on read-only variables for which SvPV_force would not need to make any changes anyway. Now, if a COW scalar is read-only, we can’t call SvPV_force on it, because it will die. It turns out that we don’t actually need to call SvPV_force on COWs. We can just go ahead and attach the BM magic and continue sharing the buffer.
* Revert "Remove the non-inline function S_croak_memory_wrap from inline.h."Tony Cook2013-07-241-11/+3
| | | | | | | | | This reverts commit 43387ee1abcd83c3c7586b7f7aa86e838d239aac. Which reverted parts of f019c49e380f764c1ead36fe3602184804292711, but that reversion may no longer be necessary. See [perl #116989]
* Fix SEGVs and test failures for -DPERL_GLOBAL_STRUCT_PRIVATENicholas Clark2013-07-121-0/+4
| | | | | | | | | | | | | With PERL_GLOBAL_STRUCT_PRIVATE "global" variables are in a structure in malloc()ed memory, not in global static variables or a global static structure. Hence no global variables are implicitly initialised to zero. * PL_curinterp and PL_op_sequence need initialising to NULL * The global structure is free()d before handlers registered with atexit() run, so be defensive about this. * Some C code checks SvOK(PL_sv_placeholder) so ensure that its SvFLAGS() are 0. * Zero PL_hash_seed
* Quiet warning in a DEBUG printPeter Martini2013-07-091-1/+1
| | | | | | The variable type is STRLEN, and the format code is expecting a UV, so just cast it to UV to quiet a warning.
* util.c: Avoid unnecessary setlocale() callsKarl Williamson2013-07-071-4/+9
| | | | | | This code sets the locale to C around its work. This is unnecessary if the locale is already C, and there is an existing global that indicates this, that can be tested to avoid the sets.
* rarest is only used under -DDEBUGGINGTony Cook2013-07-041-2/+2
| | | | This was warning under gcc 4.7.2
* change magic_methcall to use SV with shared hash valueRuslan Zakirov2013-06-301-1/+1
| | | | | | Perl_magic_methcall is not public API, so there is no need to add another function and we can just change function's arguments.
* util.c: Stop ck_index/fbm_compile from abusing readonlinessFather Chrysostomos2013-06-221-1/+3
| | | | | | | | | | | There is currently a convenient exception in sv_force_normal that allows read-only scalars to be modified at compile time. I want to get rid of it, since most code that relies on it is buggy. So stop ck_index from relying on that when it calls fbm_compile by stopping fbm_compile from triggering the error by forcing stringifica- tion of variables that are already strings.
* Stop fbm_compile from flattening refsFather Chrysostomos2013-06-221-1/+1
| | | | | | | | | References can change their stringification any time, so flattening them ahead of time for efficiency gives incorect results. Also, using a reference constant as the second argument to index would result in the constant itself being flattened, even when used elsewhere.
* Remove BmRARE and BmPREVIOUSFather Chrysostomos2013-06-211-3/+1
| | | | | These were only used by the study code, which was disabled in 5.16.0 and removed shortly thereafter.
* the code that used hstat, istat, qstat was removed in 6fd8c33aTony Cook2013-06-141-1/+0
|
* Don't ignore signals on pcloseLeon Timmermans2013-06-131-10/+0
| | | | This is a bug, per POSIX
* Eliminate the implementations of [hv]to[vh][ls] for mixed-endian systems.Nicholas Clark2013-05-201-93/+0
| | | | | | As pp_pack.c has had mixed-endian support removed, there is little point in keeping code in perl.h and util.c only needed for architectures that cannot be built.
* Eliminate Perl_my_swabn(), as it is now unused.Nicholas Clark2013-05-201-16/+0
| | | | It is not marked as part of the API, and no code on CPAN is using it.
* Eliminate my_{hto[bl]e,[bl]etoh}{16,32,64,s,i,l} as nothing now uses them.Nicholas Clark2013-05-201-139/+0
|
* Eliminate the conditionally-compiled fallback functions for htonl etc.Nicholas Clark2013-05-201-49/+0
| | | | | | | | | | | These are now only being used for mixed-endian platforms which do not provide their own htnol (etc) functions. Given that the fallbacks have been buggy since they were added in Perl 3.0, it's safe to conclude that no mixed-endian platforms were ever using these functions. It's also unclear why these functions were ever marked as 'A', part of the API. XS code can't call them directly, as it can't rely on them being compiled. Unsurprisingly, no code on CPAN references them.
* Remove buggy loop-based byte swapping code.Nicholas Clark2013-05-201-35/+3
| | | | | The irony is that the union-based code special-cased for little endian systems actually works everywhere, even on mixed-endian systems.
* Provide vtohl, vtohs, htovl and htovs no-op macros on little endian systems.Nicholas Clark2013-05-201-4/+4
| | | | | | | | | | | This means that there are always macros or functions for vtohl, vtohs, htovl and htovs available, so eliminate HAS_VTOHL etc, and unconditionally compile the code that it was protecting. grep.cpan.me shows that no code on CPAN uses any of these macros. (Technically the 4 are not quite no-ops, as they truncate their values to 32 or 16 bits, to be consistent with the implementations for platforms which need re-ordering.)
* perl #117865] [PATCH] Eliminate useless variable and sizeof(char)Dagfinn Ilmari Mannsåker2013-05-201-4/+2
| | | | | | bufsiz is always just set from bsiz (via a useless multiplication by sizeof(char), which is by definition 1), so instead of trying to keep them in sync, just get rid of bufsiz use bsiz directly# Please enter the commit message for your changes. Lines starting
* silence warnings under NO_TAINT_SUPPORTDavid Mitchell2013-05-091-1/+4
| | | | | The are lots of places where local vars aren't used when compiled with NO_TAINT_SUPPORT.
* cleanup and test PERL_PERTURB_KEYS environment variable handlingYves Orton2013-05-081-29/+33
|
* Make it possible to disable and control hash key traversal randomizationYves Orton2013-05-071-2/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Adds support for PERL_PERTURB_KEYS environment variable, which in turn allows one to control the level of randomization applied to keys() and friends. When PERL_PERTURB_KEYS is 0 we will not randomize key order at all. The chance that keys() changes due to an insert will be the same as in previous perls, basically only when the bucket size is changed. When PERL_PERTURB_KEYS is 1 we will randomize keys in a non repeatedable way. The chance that keys() changes due to an insert will be very high. This is the most secure and default mode. When PERL_PERTURB_KEYS is 2 we will randomize keys in a repeatedable way. Repititive runs of the same program should produce the same output every time. The chance that keys changes due to an insert will be very high. This patch also makes PERL_HASH_SEED imply a non-default PERL_PERTURB_KEYS setting. Setting PERL_HASH_SEED=0 (exactly one 0) implies PERL_PERTURB_KEYS=0 (hash key randomization disabled), settng PERL_HASH_SEED to any other value, implies PERL_PERTURB_KEYS=2 (deterministic/repeatable hash key randomization). Specifying PERL_PERTURB_KEYS explicitly to a different level overrides this behavior. Includes changes to allow one to compile out various aspects of the patch. One can compile such that PERL_PERTURB_KEYS is not respected, or can compile without hash key traversal randomization at all. Note that support for these modes is incomplete, and currently a few tests will fail. Also includes a new subroutine in Hash::Util::hash_traversal_mask() which can be used to ensure a given hash produces a predictable key order (assuming the same hash seed is in effect). This sub acts as a getter and a setter. NOTE - this patch lacks tests, but I lack tuits to get them done quickly, so I am pushing this with the hope that others can add them afterwards.
* fix two my_setenv/my_clearenv bugsMarkus Jansen2013-05-031-1/+3
| | | | | | | | | | | RT #117121. This commit fixes two bugs. First, some old glibc's can crash if unsetenv() is called with a null environ. Secondly, the code in Perl_my_clearenv(), when freeing env vars with a name longer than 80 chars, reallocs a tmp buffer, but didn't update the buf lencausing this to fail under valgrind: $ENV{"a"x 90}=1; local %ENV;
* Remove the non-inline function S_croak_memory_wrap from inline.h.Andy Dougherty2013-03-281-3/+11
| | | | | | | | | | | | | | | | | | | | This appears to resolve these three related tickets: [perl #116989] S_croak_memory_wrap breaks gcc warning flags detection [perl #117319] Can't include perl.h without linking to libperl [perl #117331] Time::HiRes::clock_gettime not implemented on Linux (regression?) This patch changes S_croak_memory_wrap from a static (but not inline) function into an ordinary exported function Perl_croak_memory_wrap. This has the advantage of allowing programs (particuarly probes, such as in cflags.SH and Time::HiRes) to include perl.h without linking against libperl. Since it is not a static function defined within each compilation unit, the optimizer can no longer remove it when it's not needed or inline it as needed. This likely negates some of the savings that motivated the original commit 380f764c1ead36fe3602184804292711. However, calling the simpler function Perl_croak_memory_wrap() still does take less set-up than the previous version, so it may still be a slight win. Specific cross-platform measurements are welcome.
* PATCH [perl #106212] Add PL_perlio_mutex to atfork_lock/unlockPatrik Hägglund2013-03-211-0/+6
| | | | | | | | | | | | | | Using threads + fork() on Linux, and IO operations in the threads, the PL_perlio_mutex may be left in a locked state at the call of fork(), potentially leading to deadlock in the child process at subsequent IO operations. (Threads are pre-empted and not continued in the child process after the fork.) Therefore, ensure that the PL_perlio_mutex is unlocked in the child process, right after fork(), by using atfork_lock/unlock. (The RT text gives ways to reproduce the problem, but are not easily added to Perl's test suite)
* Harden hashes against hash seed discovery by randomizing hash iterationYves Orton2013-03-191-3/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Adds: S_ptr_hash() - A new static function in hv.c which can be used to hash a pointer or integer. PL_hash_rand_bits - A new interpreter variable used as a cheap provider of "semi-random" state for use by the hash infrastructure. xpvhv_aux.xhv_rand - Used as a mask which is xored against the xpvhv_aux.riter during iteration to randomize the order the actual buckets are visited. PL_hash_rand_bits is initialized as interpreter start from the random hash seed, and then modified by "mixing in" the result of ptr_hash() on the bucket array pointer in the hv (HvARRAY(hv)) every time hv_auxinit() allocates a new iterator structure. The net result is that every hash has its own iteration order, which should make it much more difficult to determine what the current hash seed is. This required some test to be restructured, as they tested for something that was not necessarily true, we never guaranteed that two hashes with the same keys would produce the same key order, we merely promised that using keys(), values(), or each() on the same hash, without any insertions in between, would produce the same order of visiting the key/values.
* Bring core up to version-0.9902John Peacock2013-03-071-12/+16
| | | | | | | | | | | | | | The attached patch bring the core Perl version code (including a fairly significant leak when run in a tight loop) up to parity with CPAN 0.9902. This deals with all open issues except: https://rt.cpan.org/Ticket/Display.html?id=81294 which I am having a hard time modeling. John Signed-off-by: Chris 'BinGOs' Williams <chris@bingosnet.co.uk>
* Perl_instr() implement with libc equivalent.Karl Williamson2012-12-271-22/+2
| | | | | | | | | | | | | | | C89 libc contains the strstr() function that does the same thing as instr(). Convert to use it under the assumption that it is faster than our code, and is less for us to maintain. Because early versions of Lunix libc had a bug when the 'little' argument was NULL (fixed in late 1994), check for that explicitly. If we were willing to ignore issues with such old libc versions, or if we had a Configure probe that tested for the bug, we could replace the macro instr() completely with a call to strstr(). The memmem() GNU extension does the same thing as Perl_ninstr(). It however has bugs in much later libc versions. A Configure probe could be written to see if it is usable.
* uninline panic branch from POPSTACKDaniel Dragan2012-12-231-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | This commit saves machine instructions by preventing inlining, and keeps the error handling code for an extremely rare panic out of hot code. This should make the interp smaller and faster. Perl_error_log is a macro that has a very large expansion on threaded perls, 4 branches and possibly a call to Perl_PerlIO_stderr. POPSTACK 18 times, by asm, on my non DEBUGGING threaded Win32 32 bit Perl 5.17 -O1 compiled with VC 2003. POPSTACK is also used in some core XS modules, for example List::Util and PerlIO::encoding. The .text section of perl517.dll dropped from 0xc05ff bytes of x86 instructions to 0xc00ff after applying this for me. Perl_croak_popstack was made contextless to save a push/move instruction at each caller (less instructions in the instruction cache) and for more opportunity for the compiler to optimize. Since Perl_croak_popstack is a noreturn, some compilers may optimize it to just a conditional jump instruction. VC 2003 32 bit did this inside perl517.dll and from XS modules using POPSTACK. Perl_croak_popstack measures at 0x48 bytes of instructions under -O1 for me, so previously, those 0x48 minus the dTHX overhead would have been sitting in the caller because of macro expansion.
* Add diagnostics for PERL_HASH_SEED warningYves Orton2012-12-141-1/+1
|
* Use the right warn routineYves Orton2012-12-141-1/+1
|
* warn if PERL_HASH_SEED contains an unexpected characterYves Orton2012-12-141-0/+7
|
* Remove "register" declarationsKarl Williamson2012-11-241-27/+27
| | | | | | | This finishes the removal of register declarations started by eb578fdb5569b91c28466a4d1939e381ff6ceaf4. It neglected the ones in function parameter declarations, and didn't include things in dist, ext, and lib, which this does include
* Remove the EPOC port.Nicholas Clark2012-11-191-21/+6
| | | | | | | EPOC was a family of operating systems developed by Psion for mobile devices. It was the predecessor of Symbian. The port was last updated in April 2002.
* Hash Function Change - Murmur hash and true per process hash seedYves Orton2012-11-171-32/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch does the following: *) Introduces multiple new hash functions to choose from at build time. This includes Murmur-32, SDBM, DJB2, SipHash, SuperFast, and One-at-a-time. Currently this is handled by muning hv.h. Configure support hopefully to follow. *) Changes the default hash to Murmur hash which is faster than the old default One-at-a-time. *) Rips out the old HvREHASH mechanism and replaces it with a per-process random hash seed. *) Changes the old PL_hash_seed from an interpreter value to a global variable. This means it does not have to be copied during interpreter setup or cloning. *) Changes the format of the PERL_HASH_SEED variable to a hex string so that hash seeds longer than fit in an integer are possible. *) Changes the return of Hash::Util::hash_seed() from a number to a string. This is to accomodate hash functions which have more bits than can be fit in an integer. *) Adds new functions to Hash::Util to improve introspection of hashes -) hash_value() - returns an integer hash value for a given string. -) bucket_info() - returns basic hash bucket utilization info -) bucket_stats() - returns more hash bucket utilization info -) bucket_array() - which keys are in which buckets in a hash More details on the new hash functions can be found below: Murmur Hash: (v3) from google, see http://code.google.com/p/smhasher/wiki/MurmurHash3 Superfast Hash: From Paul Hsieh. http://www.azillionmonkeys.com/qed/hash.html DJB2: a hash function from Daniel Bernstein http://www.cse.yorku.ca/~oz/hash.html SDBM: a hash function sdbm. http://www.cse.yorku.ca/~oz/hash.html SipHash: by Jean-Philippe Aumasson and Daniel J. Bernstein. https://www.131002.net/siphash/ They have all be converted into Perl's ugly macro format. I have not done any rigorous testing to make sure this conversion is correct. They seem to function as expected however. All of them use the random hash seed. You can force the use of a given function by defining one of PERL_HASH_FUNC_MURMUR PERL_HASH_FUNC_SUPERFAST PERL_HASH_FUNC_DJB2 PERL_HASH_FUNC_SDBM PERL_HASH_FUNC_ONE_AT_A_TIME Setting the environment variable PERL_HASH_SEED_DEBUG to 1 will make perl output the current seed (changed to hex) and the hash function it has been built with. Setting the environment variable PERL_HASH_SEED to a hex value will cause that value to be used at the seed. Any missing bits of the seed will be set to 0. The bits are filled in from left to right, not the traditional right to left so setting it to FE results in a seed value of "FE000000" not "000000FE". Note that we do the hash seed initialization in perl_construct(). Doing it via perl_alloc() (via init_tls) causes problems under threaded builds as the buffers used for reentrant srand48 functions are not allocated. See also the p5p mail "Hash improvements blocker: portable random code that doesnt depend on a functional interpreter", Message-ID: <CANgJU+X+wNayjsNOpKRqYHnEy_+B9UH_2irRA5O3ZmcYGAAZFQ@mail.gmail.com>
* dTHX implies dVAR, using both fails to build under -DPERL_GLOBAL_STRUCTTony Cook2012-11-141-1/+1
|
* more dTHX optimizationsDaniel Dragan2012-11-121-1/+2
| | | | | Either delay fetching of the context, or move the declaration close to the first usage point, or remove the dependency on a context.
* clean up the users of PL_no_memDaniel Dragan2012-11-121-16/+19
| | | | | | | | | This commit eliminates a couple strlen()s of a literal. "Out of memory!\n" and PL_no_mem did not string pool on Visual C, so PL_no_mem was given a length. This commit removes S_write_no_mem and replaces it with nonstatic. Perl_croak_no_mem was made nocontext to save instructions in it's callers. NORETURN_FUNCTION_END caused a syntax error on Visual C C++ mode and therefore was removed.
* rmv context from Perl_croak_no_modify and Perl_croak_xs_usageDaniel Dragan2012-11-121-2/+2
| | | | | | | | | | | Remove the context/pTHX from Perl_croak_no_modify and Perl_croak_xs_usage. For croak_no_modify, it now has no parameters (and always has been no return), and on some compilers will now be optimized to a conditional jump. For Perl_croak_xs_usage one push asm opcode is removed at the caller. For both funcs, their footprint in their callers (which probably are hot code) is smaller, which means a tiny bit more room in the cache. My text section went from 0xC1A2F to 0xC198F after apply this. Also see http://www.nntp.perl.org/group/perl.perl5.porters/2012/11/msg195233.html .
* util.c: Add some asserts()Karl Williamson2012-11-111-0/+18
| | | | | | | These functions improperly have a signed parameter, when the value should always be at least 0. We have a field report that one of them is getting called with a negative value. Add asserts to catch this condition (if compiling assertions is on) earlier.
* remove various redundant dTHXesDaniel Dragan2012-11-081-4/+2
| | | | | Remove either unused dTHXes, or remove dTHXes where a nocontext func can be used instead. Smaller/faster machine code is the result.
* Add C define to remove taint support from perlSteffen Mueller2012-11-051-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | By defining NO_TAINT_SUPPORT, all the various checks that perl does for tainting become no-ops. It's not an entirely complete change: it doesn't attempt to remove the taint-related interpreter variables, but instead virtually eliminates access to it. Why, you ask? Because it appears to speed up perl's run-time significantly by avoiding various "are we running under taint" checks and the like. This change is not in a state to go into blead yet. The actual way I implemented it might raise some (valid) objections. Basically, I replaced all uses of the global taint variables (but not PL_taint_warn!) with an extra layer of get/set macros (TAINT_get/TAINTING_get). Furthermore, the change is not complete: - PL_taint_warn would likely deserve the same treatment. - Obviously, tests fail. We have tests for -t/-T - Right now, I added a Perl warn() on startup when -t/-T are detected but the perl was not compiled support it. It might be argued that it should be silently ignored! Needs some thinking. - Code quality concerns - needs review. - Configure support required. - Needs thinking: How does this tie in with CPAN XS modules that use PL_taint and friends? It's easy to backport the new macros via PPPort, but that doesn't magically change all code out there. Might be harmless, though, because whenever you're running under NO_TAINT_SUPPORT, any check of PL_taint/etc is going to come up false. Thus, the only CPAN code that SHOULD be adversely affected is code that changes taint state.
* optimize memory wrap croaks, often used in MEM_WRAP_CHECKDaniel Dragan2012-10-251-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Most perls are built with PERL_MALLOC_WRAP. This causes MEM_WRAP_CHECK macro to perform some checks on the requested allocation size in macro Newx. The checks are performed at the caller, not in the callee (for me on Win32 perl the callee in Newx is Perl_safesysmalloc) of Newx. If the check fails a "Perl_croak_nocontext("%s",PL_memory_wrap)" is done. In x86 machine code, "if(bad_alloc) Perl_croak_nocontext("%s",PL_memory_wrap); will be written as "cond jmp ahead ~15 bytes", "push const pointer", "push const pointer", "call const pointer". For each Newx where the allocation amount was not a constant (constant folding would remove the croak memory wrap branch compleatly), the branch takes 15-19 bytes depending on x86 compiler. There are about 80 Newx'es in the interp (win32 dynamic linking perl) that do the memory wrap check and have a "Perl_croak_nocontext("%s",PL_memory_wrap)" in them after all optimizations by the compiler. This patch reduces the memory wrap branch from 15-19 to 5 bytes on x86. Since croak_memory_wrap is a static and a noreturn, a compiler with IPO may optimize the whole branch to "cond jmp 32 bits relative" at each callsite. A less optimal complier may do "cond jmp 8 bits relative (jump past the "call S_croak_memory_wrap" instruction), then "call S_croak_memory_wrap". Both ways are better than the current situation. The reason why croak_memory_wrap is a static and not an export is that the compiler has more opportunity to optimize/reduce the impact of the memory wrap branch at the call site if the target is in the same image rather than in a different image, which would require using the platform specific dynamic linking mechanism/export table/etc, which often requires a new stack frame per ABI of the platform. If a dynamic linked XS module does not use S_croak_memory_wrap it will be removed from the image by the C compiler. If it is included in the XS image, it is a very small block of code and a 3 byte string litteral. A CPU cache line is typically 32 or 64 bytes and a memory read is typically 16. Cutting the instructions by 10 to 16 bytes out of "hot code" (10 of the ~80 call sites are pp_*) is a worthy goal. In a few places the memory wrap croak is used explictly, not from a MEM_WRAP_CHECK, this patch converts those to use the static. If PERL_MALLOC_WRAP is undef, there are still a couple uses of croak memory wrap, so do not keep S_croak_memory_wrap in a ifdef PERL_MALLOC_WRAP. Also see http://www.nntp.perl.org/group/perl.perl5.porters/2012/10/msg194383.html and [perl #115456].
* avoid calling memset with a negative countAndy Dougherty2012-10-171-0/+3
| | | | | | | | | | | Poorly written perl code that allows an attacker to specify the count to perl's 'x' string repeat operator can already cause a memory exhaustion denial-of-service attack. A flaw in versions of perl before 5.15.5 can escalate that into a heap buffer overrun; coupled with versions of glibc before 2.16, it possibly allows the execution of arbitrary code. The flaw addressed to this commit has been assigned identifier CVE-2012-5195.
* Bring bleadperl up to parity with CPAN for version.pmJohn Peacock2012-09-161-1/+3
| | | | | | | | | | | | | Please find attached a patch to bleadperl to bring up to date with the CPAN release of version.pm. This release was to deal primarily with an edge case in numifying alpha decimal versions: https://rt.cpan.org/Ticket/Display.html?id=79259 I've also synchronized all of the other version.pm test cases, so that the code in core is identical to the CPAN release. Signed-off-by: David Golden <dagolden@cpan.org>
* 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
|
View Lorry Controller Status