summaryrefslogtreecommitdiff
path: root/pp.c
Commit message (Collapse)AuthorAgeFilesLines
* stop lc() etc accidentally modifying in-place.David Mitchell2016-03-241-11/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As an optimisation, [ul]c() and [ul]cfirst() sometimes modify their argument in-place rather than returning a modified copy. This should only be done when there is no possibility that the arg is going to be reused. However, this fails: use List::Util qw{ first }; my %hash = ( ASD => 1, ZXC => 2, QWE => 3, TYU => 4); print first { lc $_ eq 'qwe' } keys %hash; which prints "qwe" rather than "QWE". Bascally everything in perl that sets $_ or $a/$b and calls a code block or function, such as map, grep, for and, sort, either copies any PADTMPs, turns off SvTEMP, and/or bumps the reference count. List::Util doesn't do this, and it is likely that other CPAN modules which do "set $_ and call a block" don't either. This has been failing since 5.20.0: perl has been in-placing if the arg is (SvTEMP && RC==1 && !mg) (due to v5.19.7-112-g5cd5e2d). Make the optimisation critera stricter by always copying SvTEMPs. It still allows the optimisation if the arg is a PADTMP - I don't know whether this is unsafe too. Perhaps we can think of something better after 5.24?
* Cast away Solaris Studio 12.3 warning.Jarkko Hietaniemi2016-02-041-1/+1
| | | | "pp.c", line 3220: warning: initializer will be sign-extended: -2147483648
* make gimme consistently U8David Mitchell2016-02-031-8/+8
| | | | | | | | | | | | | The value of gimme stored in the context stack is U8. Make all other uses in the main core consistent with this. My primary motivation on this was that the new function cx_pushblock(), which I gave a 'U8 gimme' parameter, was generating warnings where callers were passing I32 gimme vars to it. Rather than play whack-a-mole, it seemed simpler to just uniformly use U8 everywhere. Porting/bench.pl shows a consistent reduction of about 2 instructions on the loop and sub benchmarks, so this change isn't harming performance.
* convert CX_PUSHSUB/POPSUB to inline fnsDavid Mitchell2016-02-031-1/+1
| | | | | | Replace CX_PUSHSUB() with cx_pushsub() etc. No functional changes.
* rename POPFOO() to CX_POPFOO()David Mitchell2016-02-031-1/+1
| | | | | | | | | | | | | | | | Rename all the context-popping macros such as POPBLOCK and POPSUB, by giving them a CX_ prefix. (Do TOPBLOCK too). This is principally to deliberately break any existing non-core use of these non-API macros, as their behaviour has changed in this branch. In particular, POPBLOCK(cx) no longer decrements the cxt stack pointer nor sets cx; instead, cx is now expected to already point to the stack frame which POPBLOCK should process. At the same time, giving them a CX_ prefix makes it clearer that these are all part of a family of macros that manipulate the context stack. The PUSHFOO() macros will be renamed in a later commit.
* add CX_CUR() macroDavid Mitchell2016-02-031-3/+3
| | | | | | This is simply #define CX_CUR() (&cxstack[cxstack_ix])
* factor common code into POPSUB_ARGS()David Mitchell2016-02-031-14/+2
| | | | | | | | | Some code that is common to POPSUB() and pp_coreargs, extract out into a common macro. (There's some almost identical code in pp_goto, so add a note there). This makes pp_coreargs slightly less efficient, since it now tests for AvREAL(av), when that should never be true. But it's not exactly hot code.
* pp_coreargs: rationalise @_ codeDavid Mitchell2016-02-031-9/+14
| | | | | | Make the code in pp_coreargs that cleans up @_ more like the code in POPSUB, so that the two can eventually be extracted out into a common macro.
* pp_entersub: skip resetting @_David Mitchell2016-02-031-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | Whenever we leave a sub by whatever means (pp_leavesub, pp_return, pp_goto, die etc) it is the responsibility of the code that pops the SUB context to clean up the private @_ of that sub (i.e pad[0]) so that it's empty and not real. There's some code in pp_entersub that duplicates this check. I believe this check is unnecessary and so this commit removes it and replaces it with an assert. It was added by 221373f04 in 1999 to fix the issue described in Subject: [ID 19991015.010] [BUG 5.005_62 Assertation failed: "pp_ctl.c" line 2443] Message-Id: <19991016024500.A32541@athens.aocn.com> There were two fixes applied for this issue; the other was 0253cb4. I think the second commit actually fixed the issue and the first fix was a red herring. If my newly-added assert fails, it implies that something needs fixing in the context-popping code, rather than in pp_entersub. In fact the new assert showed up one issue: the special-case handling of @_ for &CORE::undef in pp_coreargs wasn't emptying the array, so I added a CLEAR_ARGARRAY().
* eliminate the argarray field from the CX structDavid Mitchell2016-02-031-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At the end of a normal sub call there are often 3 AVs of interest associated with @_; these are: cx->blk_sub.savearray the caller's @_ GvAV(PL_defgv) the current sub's current @_ cx->blk_sub.argarray the current sub's original @_ Note that those last two can differ: if for example the sub does local *_ = []; Each sub's arg array is created and stored in pad slot 0 at the time the sub is created. When a sub is called, pp_entersub() does cx->blk_sub.argarray = PL_curpad[0] The argarray field is used in two main places: * at subroutine exit, to clear/abandon the sub's original @_; * in pp_caller, to set @DB::args to the caller(n)'s args. In the first case, the last few commits have arranged things so that at that point, PL_curpad always points to the current pad of the sub being exited from. So we can just use PL_curpad[0] rather than cx->blk_sub.argarray. In the second case (which is not performance critical), we can just use cx->blk_sub.cv and cx->blk_sub.olddepth+1 to find the pad of that call frame's CV. So we can eliminate the argarray field. This saves a write during a sub call, and potentially reduces the size of the context struct. It also makes the code marginally less confusing: there are now 3 arrays pointed to from 3 places, rather than 3 arrays pointed to from 4 places. The asserts added in the previous commit confirmed that using argarray is the same as using PL_curpad[0]; They also confirmed that the current PL_curpad matches the current CV at the current depth. Those latter asserts are kept for now.
* assert that it's safe to remove CX.argarray fieldDavid Mitchell2016-02-031-0/+5
| | | | | This commit adds assertions that demonstrate that the next commit is safe. See the description of that commit for details.
* fix op/infnan.t test fails with NAN conversion on VC 6Daniel Dragan2016-01-281-6/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | fixes ok 443 - NAN is NaN numerically (by not being NaN) ok 444 - NAN value stringifies as NaN ok 445 - nan is NaN numerically (by not being NaN) not ok 446 - nan value stringifies as NaN ok 447 - qnan is NaN numerically (by not being NaN) not ok 448 - qnan value stringifies as NaN ok 449 - SNAN is NaN numerically (by not being NaN) not ok 450 - SNAN value stringifies as NaN ok 451 - NanQ is NaN numerically (by not being NaN) not ok 452 - NanQ value stringifies as NaN ok 453 - NANS is NaN numerically (by not being NaN) not ok 454 - NANS value stringifies as NaN ok 455 - 1.\#QNAN is NaN numerically (by not being NaN) not ok 456 - 1.\#QNAN value stringifies as NaN ok 457 - +1\#SNAN is NaN numerically (by not being NaN) not ok 458 - +1\#SNAN value stringifies as NaN ok 459 - -1.\#NAN is NaN numerically (by not being NaN) not ok 460 - -1.\#NAN value stringifies as NaN ok 461 - 1\#IND is NaN numerically (by not being NaN) not ok 462 - 1\#IND value stringifies as NaN ok 463 - 1.\#IND00 is NaN numerically (by not being NaN) not ok 464 - 1.\#IND00 value stringifies as NaN ok 465 - NAN(123) is NaN numerically (by not being NaN) not ok 466 - NAN(123) value stringifies as NaN ok 467 - NaN is not lt zero ok 468 - NaN is not == zero ok 469 - NaN is not gt zero ok 470 - NaN is not lt NaN ok 471 - NaN is not gt NaN Caused by commit 230ee21f3e from ~5.23.5. Add special casing for VC6. The NV to IV casts on VC are a function call called __ftol, skip executing the NV to IV casts if the logic test tests will follow "TARGn" branch because the NV and IV values are !=.
* *glob{FILEHANDLE} is no longer deprecatedRicardo Signes2016-01-021-2/+0
| | | | | | | | | We are now trying to use deprecation warnings only when we believe that a behavior will really be removed or made an error. Since we don't plan to do that with *glob{FILEHANDLE}, the warning is not useful and may be harmful. See discussion at [perl #127060].
* Deprecate wide chars in logical string opsKarl Williamson2015-12-161-0/+2
| | | | | | | See thread starting at http://nntp.perl.org/group/perl.perl5.porters/227698 Ricardo Signes provided the perldelta and perldiag text.
* infnan: NaN payload for mixed endian double-doublesJarkko Hietaniemi2015-12-141-2/+2
|
* pp_padav, pp_padhv whitespace onlyDavid Mitchell2015-12-141-16/+22
| | | | There was some bizarre indentation (1,2 or 3-space indents)
* [perl #126193] don't use a trash SV if no indexes are provided to pp_lsliceTony Cook2015-11-171-9/+14
|
* split pp_postdec() from pp_postinc() and improveDavid Mitchell2015-11-101-17/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | pp_postinc() handles both $x++ and $x-- (and the integer variants pp_i_postinc/dec). Split it into two separate functions, as handling both inc and dec in the same function requires 3 extra conditionals. At the same time make the code more efficient. As currently written it: 1) checked for "bad" SVs (such as read-only) and croaked; 2) did a sv_setsv(TARG, TOPs) to return a copy of the original value; 2) checked for a IOK-only SV and if so, directly incremented the IVX slot; 3) else called out to sv_inc/dec() to handle the more complex cases. This commit combines the checks in (1) and (3) into one single big check of flags, and for the simple integer case, skips 2) and does a more efficient SETi() instead. For the non-simple case, both pp_postinc() and pp_postdec() now call a common static function to handle everything else. Porting/bench.pl shows the following raw numbers for '$y = $x++' ($x and $y lexical and holding integers): before after ------ ----- Ir 306.0 223.0 Dr 106.0 82.0 Dw 51.0 44.0 COND 48.0 33.0 IND 8.0 6.0 COND_m 1.9 0.0 IND_m 4.0 4.0
* faster add, subtract, multiplyDavid Mitchell2015-11-101-9/+110
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In pp_add, pp_subtract and pp_multiply, special-case the following: * both args IV, neither arg large enough to under/overflow * both args NV. Starting in 5.8.0, the implementation of the arithmetic pp functions became a lot more complex (and famously, much slower), due to the need to support 64-bit integers. For example, formerly pp_add just converted both its args to an NV and returned an NV. On 64-bit systems, that could gave bad results if the mantissa of an NV was < 64 bits; for example: $ perl561 -e'$x = 0x1000000000000000; printf "%x\n", $x+1' 1000000000000000 $ perl580 -e'$x = 0x1000000000000000; printf "%x\n", $x+1' 1000000000000001 This led to a lot of complex code that covered all the possibilities of overflow etc. This commit adds some special casing to these three common arithmetic ops. It does some quick checks (mainly involving fast boolean and bit ops) to determine if both args are valid IVs (and not UVs), are not magic, and aren't very big (+ve or -ve). In this case, the result is simply SvIVX(svl) + SvIVX(svr) (or - or *) with no possibility of overflow. Failing that, if both args are NV's and not magic, then if both NVs can be converted to IVs without loss, handle as for the IV case; failing that, just return SvNVX(svl) + SvNVX(svr); For all other cases, such as mixed IV and NV or PV, fall back to the old code. On my platform (x86_64), it (along with the previous commit) reduces the execution time of the nbody benchmark (lots of floating-point vector arithmetic) by a third and in fact makes it 10% faster than 5.6.1.
* perl #126396 IRIX longdouble infinity issuesJarkko Hietaniemi2015-10-191-0/+10
| | | | | | | | | | | | | | | | | | | In IRIX longdouble (which uses the double-double format, bigendian) multiplying with infinity introduces garbage bytes to the second double of the double-double. This garbage, in turn, seems to tickle another bug in long doubles, in comparing infinities, where these garbage bytes errorneously matter when they should not. Workaround: zero these garbage bytes in multiplication. The garbage bytes seem to appear only the multiplication, as far as t/op/infnan.t can detect. Even though we could place the multiplication result to a temporary NV variable (for easier infiniteness inspection) for all the platforms and depend on optimizer doing away with the temporary, let's be conservative.
* optimise save/restore of PL_delaymagic.David Mitchell2015-10-181-6/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | A few places (pp_push, pp_unshift, pp_aassign) have to set PL_delaymagic on entry, and restore it on exit. These are hot pieces of code. Rather than using ENTER/SAVEI16(PL_delaymagic)/LEAVE, add an extra field to the jumpenv struct, and make the JUMPENV_PUSH / POP macros automatically save and restore this var. This means that pp_push etc only need to do a local save: U16 old_delaymagic = PL_delaymagic; PL_delaymagic = DM_DELAY; .... PL_delaymagic = old_delaymagic; and in case of an exception being raised, PL_delaymagic still gets restored. This transfers the cost of saving PL_delaymagic from each call to pp_aassign etc to each time a new run level is invoked. The latter should be much less frequent. Note that prior to this commit, pp_aassign wasn't actually saving and restoring PL_delaymagic; it was just setting it to 0 at the end. So this commit also makes pp_aassign safe against PL_delaymagic re-entrancy like pp_push and pp_unshift already were.
* Delay @ISA magic while unshiftingDagfinn Ilmari Mannsåker2015-10-181-2/+9
| | | | | | | | | | | | | | | | | pp_unshift() first calls av_unshift(), which prepends the the requisite number of undefs, then calls av_store() for each item. However, unlike pp_push() it was not setting PL_delaymagic around the av_store() loop, so when unshifting onto @ISA, its magic would be triggered while there were still undefs in the array, causig the following spurious warning: $ perl -wE 'package Foo; unshift @ISA, qw(A B)' Use of uninitialized value in unshift at -e line 1. Also fix pp_push() to save and restore PL_delaymagic instead of clearing it, so that e.g. unshifting a tied value with FETCH pushing onto another @ISA doesn't erroneously clear the value from underneath the unshift.
* Future-proof pp_trans against a possible future undefined behaviourVincent Pit2015-10-051-1/+2
| | | | | | If do_trans() ever wants to modify the stack in the future, this would cause an undefined behaviour as mPUSHi() invokes its parameter on the same argument list as PUSHmortal, which itself touches the stack.
* fix up EXTEND() callersDavid Mitchell2015-10-021-13/+16
| | | | | | | | | | | | | | | | | | | | | | The previous commit made it clear that the N argument to EXTEND() is supposed to be signed, in particular SSize_t, and now typically triggers compiler warnings where this isn't the case. This commit fixes the various places in core that passed the wrong sort of N to EXTEND(). The fixes are in three broad categories. First, where sensible, I've changed the relevant var to be SSize_t. Second, where its expected that N could never be large enough to wrap, I've just added an assert and a cast. Finally, I've added extra code to detect whether the cast could wrap/truncate, and if so set N to -1, which will trigger a panic in stack_grow(). This also fixes [perl #125937] 'x' operator on list causes segfault with possible stack corruption
* pp.c:pp_reverse: Don’t use find_rundefsvFather Chrysostomos2015-09-291-1/+1
| | | | It just calls DEFSV now, so use DEFSV directly.
* In pp.c:pp_coreargs, use DEFSV directlyFather Chrysostomos2015-09-291-4/+1
| | | | | rundefsv2 is only necessary for lexical $_. It’s slower than a simple DEFSV, which is what it falls back to anyway.
* Add macro for converting Latin1 to UTF-8, and use itKarl Williamson2015-09-041-1/+1
| | | | | | | | | This adds a macro that converts a code point in the ASCII 128-255 range to UTF-8, and changes existing code to use it when the range is known to be restricted to this one, rather than the previous macro which accepted a wider range (any code point representable by 2 bytes), but had an extra test on EBCDIC platforms, hence was larger than necessary and slightly slower.
* Change to use UVCHR_SKIP over UNI_SKIPKarl Williamson2015-09-041-2/+2
| | | | | | | | | | UNI_SKIP is somewhat ambiguous. Perl has long used 'uvchr' as part of a name to mean the unsigned values using the native character set plus Unicode values for those above 255. This also changes two calls (one in dquote_static.c and one in dquote_inline.h) to use UVCHR_SKIP; they should not have been OFFUNI, as they are dealing with native values.
* pp.c: White-space onlyKarl Williamson2015-09-031-1/+2
| | | | Make it easier to grok what comprises the 'if'
* Safefree(NULL) reductionDaniel Dragan2015-08-031-15/+16
| | | | | | | | | | | | | | | | locale.c: - the pointers are always null at this point, see http://www.nntp.perl.org/group/perl.perl5.porters/2015/07/msg229533.html pp.c: - reduce scope of temp_buffer and svrecode, into an inner branch - in some permutations, either temp_buffer is never set to non-null, or svrecode, in permutations where it is known that the var hasn't been set yet, skip the freeing calls at the end, this doesn't eliminate all permutations with NULL being passed to Safefree and SvREFCNT_dec, but only some of them regcomp.c - dont create a save stack entry to call Safefree(NULL), see ticket for this patch for some profiling stats
* pp.c: Fix typo in commentKarl Williamson2015-08-011-1/+1
|
* uc(sharp s) is itself in very early Unicode versionsKarl Williamson2015-07-281-0/+4
|
* There are no folds to multiple chars in early Unicode versionsKarl Williamson2015-07-281-0/+6
| | | | | Several places require special handling because of this, notably for the lowercase Sharp S, but not in Unicodes before 3.0.1
* Delete experimental autoderef featureAaron Crane2015-07-131-42/+1
|
* Left overshift of negatives under use integer was still wrong.Jarkko Hietaniemi2015-07-031-1/+1
| | | | | Follow-up on b3498293: the -1 stuckiness on overshift should apply only on right shift, not left shift (which should return zero).
* Define left/right shift by negative to mean the reverse shiftJarkko Hietaniemi2015-06-281-8/+35
| | | | | | | | | | | | | | Coverity CIDs 104765 and 104766 While at it, also define shifting by more than wordsize in bits to be zero, except that undef 'use integer' (use IVs) right overshift for negative shiftees means -1. (This is another corner where C leaves things undefined. A common behavior is "shift by modulo worbits", so that e.g. 1 >> 64 == 1 >> (64 % 64) == 1 >> 0, but this is completely accidental.) (Coverity didn't flag this, harder to detect statically.) Discussion thread at http://www.nntp.perl.org/group/perl.perl5.porters/2015/06/msg228842.html
* assert(arg) before derefing it since it can be NULL.Jarkko Hietaniemi2015-06-261-7/+10
| | | | Coverity CID 104813.
* assert(key) before it is derefed.Jarkko Hietaniemi2015-06-261-1/+4
| | | | Coverity CID 104855.
* Replace common Emacs file-local variables with dir-localsDagfinn Ilmari Mannsåker2015-03-221-6/+0
| | | | | | | | | | | | | | | | An empty cpan/.dir-locals.el stops Emacs using the core defaults for code imported from CPAN. Committer's work: To keep t/porting/cmp_version.t and t/porting/utils.t happy, $VERSION needed to be incremented in many files, including throughout dist/PathTools. perldelta entry for module updates. Add two Emacs control files to MANIFEST; re-sort MANIFEST. For: RT #124119.
* repeat op: avoid integer overflowsDavid Mitchell2015-03-191-15/+20
| | | | | | | | | | | | | | | | | | | | | | | | For the list variant of the x operator, the overflow detection code doesn't always work, resulting in the stack not being extended enough. There are two places where an overflow could occur: calculating how many stack items to extend by (items * count), and passing to repeatcpy() how many bytes to copy 'items' SV pointers (items * sizeof(const SV *)). The overflow detection was generally a mess; checking for overflow using a value (max) that may have already overflown; checking whether 'max' had overflown incorrectly, and not checking (items * sizeof(const SV *) at all (perhaps hoping that the other checks would be a superset of this). Also, some of the vars were still I32s; promote to 64-bit capable types. Finally, the signature of Perl_repeatcpy() still has an I32 len; that really should be changed to IV at some point; but for now I've just ensured that the callers (list 'x' and scalar 'x') don't wrap. I haven't put in a check for the only other core caller of repeatcpy(), S_study_chunk(), since that would only become an issue compiling a pattern with a fixed or floating substr within it of length > 2**31.
* pp.c: remove unneeded SPAGAIN'sDavid Mitchell2015-03-051-2/+2
| | | | | | | Spotted by Coverity. I've left the SPAGAIN but commented out, in case future changes to the code make them needed again.
* 5th arg to indicate numeric bitwise overloadingFather Chrysostomos2015-01-311-3/+3
|
* Add string- and number-specific bitop typesFather Chrysostomos2015-01-311-18/+125
| | | | | and also implement the pp functions, though nothing compiles to these ops yet.
* avoid C labels in column 0David Mitchell2015-01-211-1/+1
| | | | | | | | | Generally the guideline is to outdent C labels (e.g. 'foo:') 2 columns from the surrounding code. If the label starts at column zero, then it means that diffs, such as those generated by git, display the label rather than the function name at the head of a diff block: which makes diffs harder to peruse.
* Add :const anon sub attributeFather Chrysostomos2015-01-191-0/+11
|
* Catch infnan repeat counts.Jarkko Hietaniemi2015-01-111-8/+17
| | | | | | | | Not entirely convinced this is worth the extra code but getting "Negative repeat count" warning for NaN repeat count is too much. Even before this patch, "a" x $Inf didn't go all Genghis over your virtual memory. This is all about the right warning.
* pp.c pp_split GvAVn can't return NULLDaniel Dragan2015-01-051-0/+3
| | | | | | | clang optimized the function call free branch of GvAVn to skip the "if (ary)" test, but the function call creation branch also will never return NULL (but no CC knows that) so use goto to skip the test on both halfs of GvAVn.
* fix more -IV_MIN negationsDavid Mitchell2014-12-311-5/+9
| | | | | | | | | Doing uv = -iv is undefined behaviour if iv happens to be IV_MIN. This occurs in several places in the perl sources. These ones were found by visual code inspection rather than using -fsanitize=undefined, but I've added extra tests so that -fsanitize could find them now.
* fix -IV_MIN negationsDavid Mitchell2014-12-311-6/+10
| | | | | | | | | | | Doing uv = -iv is undefined behaviour if iv happens to be IV_MIN. This occurs in several places in the perl sources. Found by -fsanitize=undefined. Here's a typical message: sv.c:2864:7: runtime error: negation of -9223372036854775808 cannot be represented in type 'IV' (aka 'long'); cast to an unsigned type to negate this value to itself
* Don't raise 'poorly supported' locale warning unnecessarilyKarl Williamson2014-12-291-8/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 8c6180a91de91a1194f427fc639694f43a903a78 added a warning message for when Perl determines that the program's underlying locale just switched into is poorly supported. At the time it was thought that this would be an extremely rare occurrence. However, a bug in HP-UX - B.11.00/64 causes this message to be raised for the "C" locale. A workaround was done that silenced those. However, before it got fixed, this message would occur gobs of times executing the test suite. It was raised even if the script is not locale-aware, so that the underlying locale was completely irrelevant. There is a good prospect that someone using an older Asian locale as their default would get this message inappropriately, even if they don't use locales, or switch to a supported one before using them. This commit causes the message to be raised only if it actually is relevant. When not in the scope of 'use locale', the message is stored, not raised. Upon the first locale-dependent operation within a bad locale, the saved message is raised, and the storage cleared. I was able to do this without adding extra branching to the main-line non-locale execution code. This was done by adding regnodes which get jumped to by switch statements, and refactoring some existing C tests so they exclude non-locale right off the bat. These changes would have been necessary for another locale warning that I previously agreed to implement, and which is coming a few commits from now. I do not know of any way to add tests in the test suite for this. It is in fact rare for modern locales to have these issues. The way I tested this was to temporarily change the C code so that all locales are viewed as defective, and manually note that the warnings came out where expected, and only where expected. I chose not to try to output this warning on any POSIX functions called. I believe that all that are affected are deprecated or scheduled to be deprecated anyway. And POSIX is closer to the hardware of the machine. For convenience, I also don't output the message for some zero-length pattern matches. If something is going to be matched, the message will likely very soon be raised anyway.
View Lorry Controller Status