summaryrefslogtreecommitdiff
path: root/t
Commit message (Collapse)AuthorAgeFilesLines
* (perl #132063) we should no longer warn for this codeTony Cook2018-03-231-3/+0
| | | | | | | | | | The first patch for 132063 prevented the buffer read overflow when dumping the warning but didn't fix the underlying problem. The next change treats the supplied buffer correctly, preventing the non-UTF-8 SV from being treated as UTF-8, preventing the warning. (cherry picked from commit 1e8b61488f195e1396aa801c685340b156104f4f)
* v5.24.3: fix TRIE_READ_CHAR and DECL_TRIE_TYPE to account for non-utf8 targetYves Orton2018-03-231-0/+1
| | | | (cherry picked from commit 7304de2a32efe1324d229724a46efb6c33817208)
* [perl #132063]: Heap buffer overflowKarl Williamson2018-03-231-0/+7
| | | | | | | | | | | The proximal cause is several instances in regexec.c of the code assuming that the input was valid UTF-8, whereas the input was too short for what the start byte claimed it would be. I grepped through the core for any other similar uses, and did not find any. (cherry picked from commit fe7d8ba0a1bf567af8fa8fea128e2b9f4c553e84)
* (perl #131844) fix various space calculation issues in pp_pack.cTony Cook2018-03-231-1/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - for the originally reported case, if the start/cur pointer is in the top 75% of the address space the add (cur) + glen addition would overflow, resulting in the condition failing incorrectly. - the addition of the existing space used to the space needed could overflow, resulting in too small an allocation and a buffer overflow. - the scaling for UTF8 could overflow. - the multiply to calculate the space needed for many items could overflow. For the first case, do a space calculation without making new pointers. For the other cases, detect the overflow and croak if there's an overflow. Originally this used Size_t_MAX as the maximum size of a memory allocation, but for -DDEBUGGING builds realloc() throws a panic for allocations over half the address space in size, changing the error reported for the allocation. For non-DEBUGGING builds the Size_t_MAX limit has the small chance of finding a system that has 3GB of contiguous space available, and allocating that space, which could be a denial of servce in some cases. Unfortunately changing the limit to half the address space means that the exact case with the original issue can no longer occur, so the test is no longer testing against the address + length issue that caused the original problem, since the allocation is failing earlier. One option would be to change the test so the size request by pack is just under 2GB, but this has a higher (but still low) probability that the system has the address space available, and will actually try to allocate the memory, so let's not do that. (cherry picked from commit f5506feddde8546eabb69d71569d856c7e9c615b)
* properly check readpipe()'s argument listZefram2018-03-021-3/+24
| | | | | | | | readpipe() wasn't applying context to its argument list, resulting in readpipe()'s context leaking in, and broken stack discipline when a list expression was used. Fixes [perl #4574]. (cherry picked from commit 397baf232086e0a9ad6f881a9614d3dbaea853fc)
* (perl #131665) avoid a buffer overflow in a buffer we didn't needTony Cook2017-09-101-5/+16
| | | | | | | | | since Lookup() treats its argument as NUL or '=' terminated. Previously environment variable names longer than the size of the buffer would result in a buffer overflow. (cherry picked from commit 8586647e338e8eb42c00fe6f687105c9b8a36d44)
* Regression test for RT #129196Dan Collins2017-08-231-1/+5
| | | | (cherry picked from commit a6128716d2cc20147851e0a37768376647bd3242)
* Test data mistake was masked by mistaken fractional matchingJarkko Hietaniemi2017-08-091-1/+1
| | | | | | (Affected only double-double.) (cherry picked from commit 1bee6aebe39da1a4d681e8ea1b9d0329898a8407)
* Do not deploy the fractional matching without fractionsJarkko Hietaniemi2017-08-091-1/+1
| | | | (cherry picked from commit dd1645173d8209e05c419b0f3edc9b1c0f9643a8)
* Test subnormals with quadmathJarkko Hietaniemi2017-08-091-0/+20
| | | | (cherry picked from commit de1a8b537348227e83c8efd15d3cb36d9ac646f5)
* Handle subnormals of x86 80-bitJarkko Hietaniemi2017-08-091-5/+17
| | | | (cherry picked from commit f40ac91c3b9891b83f3d253861009c290584b646)
* Use library testing for subnormalityJarkko Hietaniemi2017-08-091-2/+13
| | | | | | | | ...instead of implementing it brokenly Continuing work on rt.perl.org #128843 (cherry picked from commit f5a466613ec0b74a224adb5b7da6da0a74713596)
* Follow-up on a149d118.Jarkko Hietaniemi2017-08-091-2/+5
| | | | | | | | The added tests were meant only for x86-80-bit long doubles, but were accidentally run also on 128-bit doubles (quadmath, or probably also on true IEEE 754 quadruples). (cherry picked from commit 7301378635b35757b228e07c14276afaf06a4728)
* [perl #128919] limited exponent range in hex fp literal with long doubleJarkko Hietaniemi2017-08-091-1/+11
| | | | (cherry picked from commit a149d1180209525972d84fd1a62f488da83e568a)
* Avoid test noise on non-longdouble.Jarkko Hietaniemi2017-08-091-1/+1
| | | | (cherry picked from commit 9e67a8c1b21482ed5fada053dd462eb23320dc86)
* [rt.perl.org #128909] printf %a mishandles exponent-crossing rounding with ↵Jarkko Hietaniemi2017-08-091-2/+7
| | | | | | long double (cherry picked from commit ee58923a8531731f8acb98ab130abf41f75ebdc7)
* Bogus skip count.Jarkko Hietaniemi2017-08-091-1/+1
| | | | | | Didn't break anything but still bogus. (cherry picked from commit 44348173fce5aaf28fdf59ba6ace73ea435d9380)
* Test new hexfp fixes also on (x86 80-bit) long doubles.Jarkko Hietaniemi2017-08-091-74/+95
| | | | (cherry picked from commit e3f7a67e8485950fdf5fd9c7131d0a78b6c8cf32)
* Fix on top of 75326c48.Jarkko Hietaniemi2017-08-091-1/+1
| | | | | | | Worked partly accidentally, and as a bonus caused asan off-stack-variable read violations. (cherry picked from commit 5208a0305e9e82c534fa034515d54a0409dfcc77)
* The new tests are valid only for IEEE 754 64-bit doubles.Jarkko Hietaniemi2017-08-091-45/+45
| | | | | | | | | | | | | | | | | | | | | | | The tests do not fail (I wish), they would just need to be different for example for the 80-bt x86 long doubles, for example, which scale differently: perl -wle 'printf "%a\n", -1.5' # IEEE 754 64-bit -0x1.8+0 perl -wle 'printf "%a\n", -1.5' # x86 80-bit -0xcp-3 In any system: perl -wle 'print -0x1.8p+0' -1.5 perl -wle 'print -0xcp-3' -1.5 See earlier in this file a long if-elsif chain when testing the @hexfloat because of this very same reason. (cherry picked from commit 749d85343f3cdb65891a5fe3b9f55ef3a5b03ca8)
* [rt.perl.org #128893]: printf %a botches 0 flag for negative valuesJarkko Hietaniemi2017-08-091-1/+10
| | | | (cherry picked from commit be93048a43d87d317acca5b37619111b6a5f8c44)
* [rt.perl.org #128890]: printf %a rounds incorrectlyJarkko Hietaniemi2017-08-091-2/+29
| | | | (cherry picked from commit 75326c485e9d40be5c22d508f581cdea68b244ce)
* [rt.perl.org #128889]: printf %a mishandles negative pseudo-precisionJarkko Hietaniemi2017-08-091-1/+4
| | | | | | (the fix for [rt.perl.org #128888] fixed also this one) (cherry picked from commit a9ce335538454d590920dab8d62db84948f1fb83)
* [rt.perl.org #128888]: printf %a mishandles zero precisionJarkko Hietaniemi2017-08-091-1/+6
| | | | (cherry picked from commit 82229f9f47d9a169b59715582fb5a09b5a4ac0ff)
* Add rt.perl.org reference for b6d9b423Jarkko Hietaniemi2017-08-091-0/+1
| | | | (cherry picked from commit 94d00769fba240ffb86f18b3d66341fb1d24ae6c)
* hexfp: IEEE 754 subnormals printf %aJarkko Hietaniemi2017-08-091-1/+43
| | | | (cherry picked from commit b6d9b423fab1963346eb79e83b356114396b1f2e)
* [perl #128951] Fix ASan error with @{\327Father Chrysostomos2017-08-091-2/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | By \327 I mean character number 327 in octal. Without memory tools like ASan, it produces garbled output. The added test fails like this: Dave Mitchell’s explanation from the RT ticket: > The src code contains the bytes: > > @ { \327 \n > > after seeing "@{" the lexer calls scan_ident(), which sees the \327 as an > ident, then calls S_skipspace_flags() to skip the spaces following the > ident. This moves the current cursor position to the \n, and since that's > a line boundary, its updates PL_linestart and PL_bufptr to point to \n > too. > > When it finds that the next char isn't a '}', it does this: > > /* Didn't find the closing } at the point we expected, so restore > state such that the next thing to process is the opening { and */ > s = SvPVX(PL_linestr) + bracket; /* let the parser handle it */ > > i.e. it moves s back to the "{\317" then continues. > > However, PL_linestart doesn't get reset, so later when the parser > encounters the \327 and tries to croak with "Unrecognized character %s ...", > when it prints out the section of src code in error, since s < PL_linestr, > negative string lengths and ASAN errors ensue. This commit fixes it by passing the LEX_NO_INCLINE flag (added by 21791330a), which specifies that we are not trying to read past the newline but simply peek ahead. In that case lex_read_space does not reset PL_linestart. But that does cause problems with code like: ${; } because we end up jumping ahead via skipspace without updating the line number. So we need to do a skipspace_flags(..., LEX_NO_INCLINE) first (i.e., peek ahead), and then when we know we don’t need to go back again we can skipspace(...) for real. (cherry picked from commit bf8a9a15ea4a7b7ebcde5ba48aafe397c549eff2)
* [perl #128597] Crash from gp_free/ckWARN_dFather Chrysostomos2017-08-091-1/+17
| | | | | | | | | See the explanation in the test added and in the RT ticket. The solution is to make the warn macros check that PL_curcop is non-null. (cherry picked from commit a2637ca0a3fec01b80d7ea5ba62802354fd5e6f3)
* [perl #128204] Fix crash with @a &.= etc.Father Chrysostomos2017-08-081-0/+48
| | | | | | | | | | | | | The new bitwise operators in their assignment forms were not correctly catching things like arrays on the lhs at compile time. At run time, they would either crash or croak with ‘Can’t coerce ARRAY...’. This commit puts in the correct compile-time check, simply by flagging these as scalar modifiers. (cherry picked from commit 76734a3218e712760695898e424c2369ccdd49c6)
* [perl #128171] Fix assert fail with /@0{0*->@*/*0Father Chrysostomos2017-08-081-1/+7
| | | | | | | | | | | | | | | | | | | | | | | If a syntax error such as * (multiply) followed by an arrow causes the parser to pop scopes in trying to recover from the error, it might exit the quote-parsing scope (for parsing the regexp) and point the lexer’s cursor at the code following the regexp, after the lexer has noted to itself that it is expected to parse a postfix dereference (PL_expect==XPOSTDEREF). The code for parsing a postfix dereference has an assertion which ends up failing in this case, because the *0 following the regexp, having sigil that can come after an arrow, goes through the postfix deref function, which complains about the 0 it did not expect. If we simply remove the assertion, the lexer will continue to emit tokens, and we just end up dying (somewhat) gracefully because of the syntax error, instead of crashing. I used a ] in the test instead of a final 0, to avoid a compile- time warning. (Number found where operator expected.) (cherry picked from commit d674449463a15ac3f36086e3a0bb3a9d02729887)
* [perl #128106] Fix reset with non-globsFather Chrysostomos2017-08-081-1/+11
| | | | | | | reset with a string argument was assuming that anything in a stash would be a glob. It crashed on anything else. (cherry picked from commit fcd130693a9e7a753f63a08691ff619ad91bf8eb)
* [perl #128086] Test the prev commitFather Chrysostomos2017-08-081-1/+8
| | | | (cherry picked from commit 7f1bd063e5aa5aeb26ed9c39db6864cc0ecd7a73)
* [perl #127952] misoptimization for negated constant-ish on lhs of logopAaron Crane2017-08-081-1/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Negations were being incorrectly deleted from the op tree for an OP_AND or OP_OR (corresponding to Perl code with any of `&& || and or`, or postfix "if" or "unless") whose left-hand side looks like "!BAREWORD" or "!do { 'const' }" and whose right-hand side is a non-constant-foldable negation. The symptom in the reported case was an assertion failure in ck_refassign for an srefgen op, caused by such an OP_NOT having been nulled. But other cases exist that instead yielded incorrect results. The underlying cause is that two optimisations in S_new_logop() were partially interfering with each other. One of those attempts to optimise code like "!$x && !$y" to the equivalent of "!($x || $y)", saving a negation op; this is valid by De Morgan's laws. If it detects code of this form, it nulls out the negations on each side of the "&&", and makes a note to wrap the op it generates inside a new OP_NOT. The other optimisation looks at the left-hand arm, and if it's a constant at compile time, avoids the entire logop in favour of directly evaluating the lhs or rhs as appropriate, and eliding whichever arm is no longer needed. This optimisation is important for code like this: use constant DEBUG => …; print_debug_output() if DEBUG; because it allows the entire statement to be eliminated when DEBUG is false. When both conditions were true simultaneously, the De Morgan optimisation was applied before the constant-based arm elision. But the arm elision involved returning early from S_new_logop(), so the code later in that function that wraps the generated op in a new OP_NOT never had a chance to run. This meant that "!X && !Y" when X is constant was being compiled as if it were in fact "X || Y", which is clearly incorrect. This is, however, a very rare situation: it requires the lhs to be an OP_NOT that dominates an OP_CONST (possibly with some intervening OP_LINESEQ or similar). But OP_NOT is constant-foldable, so that doesn't normally happen. The two ways for it to happen are: - The constant is a bareword (since even though barewords are constants, they don't currently participate in constant folding) - The constant is hidden inside one or more layers of do{} (since that serves as a barrier to constant folding, but the arm-elision optimisation is smart enough to search recursively through the optree for the real constant) The fix is much simpler than the explanation: apply the optimisations in the opposite order, so that when arm elision returns early, the negation ops haven't yet been nulled. (cherry picked from commit f15d05806fb7522031b75cb5a8784727ae03b98a)
* PATCH: [perl #129122] regex sets syntax errorKarl Williamson2017-07-282-3/+18
| | | | | | | | | | This was caused by two statements being in the wrong order. One should save something on the stack before changing it, not after. However fixing this led to the discovery of another bug in which an error case was failed to be detected. (cherry picked from commit c333712c4a550eeb3146b964d8508f772e294a49)
* [perl #126482] Fix assert fail ‘a_const a_const’Father Chrysostomos2017-07-281-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Mentioning a constant twice in a row results in an assertion failure: $ ./miniperl -e 'sub ub(){0} ub ub' Assertion failed: (SvTYPE(cv) == SVt_PVCV || SvTYPE(cv) == SVt_PVFM), function Perl_cv_const_sv_or_av, file op.c, line 7926. Abort trap: 6 A bisect points to 2eaf799e7, but I don’t understand why that commit introduced it. I suspect it was failing an assertion for a slightly different reason back then, but am too lazy to check. In any case, it fails now because, while ‘ub ub’ is being compiled, when the sub is looked up initially (in toke.c:yylex), we call rv2cv_op_cv with the RV2GVOPCV_RETURN_STUB flag, which allows a bare constant ref to be returned. So the ‘cv’ variable contains an RV (\0): cv = lex ? isGV(gv) ? GvCV(gv) : SvROK(gv) && SvTYPE(SvRV(gv)) == SVt_PVCV ? (CV *)SvRV(gv) : ((CV *)gv) : rv2cv_op_cv(rv2cv_op, RV2CVOPCV_RETURN_STUB); (‘ub’ here is a constant 0, which is stored in the symbol table as \0; i.e., ‘sub ub(){0}’ is equivalent to ‘BEGIN { $::{ub} = \0 }’.) Then if we see a word immediately following it (the second ‘ub’) we check a little further down to see whether it might be a method call. That entails calling intuit_method, which does this: indirgv = gv_fetchpvn_flags(tmpbuf, len, ( UTF ? SVf_UTF8 : 0 ), SVt_PVCV); if (indirgv && GvCVu(indirgv)) return 0; So we are looking to see whether the second word refers to a sub and deciding this is not an indirect method call if there is a sub. But calling gv_fetchpvn_flags like that has the effect of upgrading the symbol table entry to a full GV. Since the ‘cv’ variable in yylex points to that symbol table entry, it ends up pointing to a GV, which certain code later on does not expect to happen. So we should pass the GV_NOADD_NOINIT flag to gv_fetchpvn_flags to prevent lookup of the second bareword from upgrading the entry (we already do that earlier in intuit_method for the first bareword). We only check the GV to see whether it has a sub or io thingy in it any- way, so we don’t actually need a full GV. (As a bonus, GvIO will already work on a non-GV and return NULL, so that part of the code remains unchanged.) (cherry picked from commit c82de78e3ba0184f85b5b49245e5da32d1cb3fcc)
* PATCH: [perl #128734] tr/\N{...}/ failing for 128-255Karl Williamson2017-07-281-1/+10
| | | | | | | | | The upper latin1 characters when expressed as \N{U+...} were failing. This was due to trying to convert them to UTF-8 when the result isn't UTF-8. I added a test for \N{name} as well, though these were not affected by this regression. (cherry picked from commit 3a34ca0bce7835211b45e070373cf653c253636a)
* PATCH: [perl #128170] Assert fail in regcomp.cKarl Williamson2017-07-281-0/+1
| | | | | | | | | | | | This fixes a regression in 5.24, bisected to commit commit cfbef7dc3bfb89e4ed2c00ea9c9e3bcfd0b170fd Author: Karl Williamson <khw@cpan.org> Date: Wed Feb 10 16:27:13 2016 -0700 regcomp.c: Fix some parsing glitches (cherry picked from commit f2e32b2c677945ce6a36531a7cd5696dc1ca2cef)
* [perl #128313] Fix leak in perl 5.24 with strict and regex posix char classesYves Orton2017-07-281-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | move warning text to RExC_state (via RExC_warn_text) This way we reuse the same AV each time, and avoid various refcount bookkeeping issues, all at a relatively modest cost (IMO) This patch is the result of detective work and inital patches by Dan Collins with additional coding to take advantage of the regexp engine internals by Yves Orton after feedback from Karl Williams. It is a squash of the following commits in blead: 222c4b0094b4145d06cb164bedd2a66a3141203b [perl #128313] test for memory leak in POSIX classes 0bf54b1ecaec8f6d80845d6cb77d62f8c9f4c415 fixup, guard av_top_index() for null RExC_warn_text 7eec73eb790f7c4982edfc28c17c011e8a072490 move warning text to RExC_state (via RExC_warn_text) ee072c898947f5fee316f1381b29ad692addcf05 [perl #128313] Fix leak in perl 5.24 with strict and regex posix char classes (cherry picked from commit dfd347fdcdbaf5a157586b05825005dc352b0e83)
* [perl #128508] Fix line numbers with perl -xFather Chrysostomos2017-07-282-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When lex_start is invoked with an SV and a handle pointer, it expects the SV to contain the beginning of the code to be parsed. The handle will be read from for subsequent code. The -x command line option happens to invoke lex_start with two non- null pointers like this (a line and a handle), since, to find the #!perl line, it has to read that first line out of the file handle. There is a line of code in lex_start that adds "\n;" to the buffer goes back to 8990e30710 (perl 5.0 alpha 6) and string eval fails catastrophically without it. As of v5.19.1-485-g2179133 multiple lines are supported in the current parsing buffer (PL_linestr) when there is a file handle, and as of v5.19.3-63-gbf1b738 the line number is correctly incremented when the parser goes past a newline. So, for -x, "#!perl\n" turns into "#!perl\n\n" (the final ; is skipped as of v5.19.3-63-gbf1b738 if there is a handle). That throws line numbers off by one. In the case where we have a string to parse and a file handle, the extra "\n;" added to the end of the buffer turns out to be completely unnecessary. So this commit makes it conditional on rsfp. The existing tests for -x are quite exotic. I have made no effort to make them less so. (cherry picked from commit b3dd0aba3d2bf0b22280303ef6f068e976e31888)
* (perl #128316) preserve errno from failed system callsTony Cook2017-07-281-0/+22
| | | | (cherry picked from commit 3f6b66c14467c0f8c7459e32c576618155ca89f3)
* [perl #128182] Fix crash with require $nonstringFather Chrysostomos2017-07-281-1/+9
| | | | | | | | | | If something other than a plain string (e.g. a reference or typeglob) whose stringified form contains a null character is passed to require() or do(), it crashes, as of v5.19.3-130-gc8028aa, because the code in question that handles the error tries to read fields of the scalar that are only valid if it is a string internally. (cherry picked from commit 08f800f8519574aea9e744ff83230fb93772652b)
* Revert "Bulk revert regex recursion fixes - REVERT THIS PATCH AFTER 5.24.2"Steve Hay2017-07-191-0/+2
| | | | This reverts commit 9ecaf4dba7ccf61301f3a0ca342810f57060fbd6.
* Bulk revert regex recursion fixes - REVERT THIS PATCH AFTER 5.24.2Yves Orton2017-05-031-2/+0
| | | | | | | | | | | | | | Revert "Add tests for regex recursion" This reverts commit 78b60e17093d684bb07f20fc953075801b1ce207. Revert "fix #128109 - do not move RExC_open_parens[0] in reginsert" This reverts commit 4539ae3741e1a4de9a54e5bc52524b40abc2d58a. Revert "fix #128085 - SIGSEGV in S_regmatch with S_study_chunk: Assertion "!frame" failed." This reverts commit 5edefd5d2abb0a8696bd2159e1f17b5975257818.
* Add tests for regex recursionDan Collins2017-05-021-0/+2
| | | | | | | d5a00e4af introduced a bug in reginsert that was fixed by da7cf1cc7, originally documented in [perl #128109]. This patch adds two regression tests for the testcase reported by Jan Goyvaerts in [perl #128420].
* Fix checks for tainted dir in $ENV{PATH}Father Chrysostomos2017-02-231-1/+17
| | | | | | | | | | | | | | | | | | | | $ cat > foo print "What?!\n" ^D $ chmod +x foo $ ./perl -Ilib -Te '$ENV{PATH}="."; exec "foo"' Insecure directory in $ENV{PATH} while running with -T switch at -e line 1. That is what I expect to see. But: $ ./perl -Ilib -Te '$ENV{PATH}="/\\:."; exec "foo"' What?! Perl is allowing the \ to escape the :, but the \ is not treated as an escape by the system, allowing a relative path in PATH to be consid- ered safe. (cherry picked from commit ba0a4150f6f1604df236035adf6df18bd43de88e)
* PATCH: [perl #129038] Crash with s///lKarl Williamson2017-02-231-1/+18
| | | | | | | The cause of this was bad logic. It thought it was dealing with UTF-8 when it wasn't. (cherry picked from commit 109ac342a6bc5a3a67c3b52341607100cedafdf7)
* Revert base.pm part of "(perl #127834) update CUSTOMIZED entries"Steve Hay2016-12-301-1/+0
| | | | | | | | | | | | | This reverts the base.pm part of commit 7c3b0dfedc689b14211a4f0445d788c7d829256c. It also reverts the later commits 864470e44daa6deaeb9457a408563146daffffca, 30222baf8c8b4c9785e63829370d1220e1d1a09f and 91fdb36ec4a24fb3d43cb8f7467d836fe2c894da, which updated customized.dat for various base.pm changes that have since been reverted. base.pm is now as it was in perl-5.24.0, which was not actually in sync with base-2.23 but had no customized.dat entry since files in dist/ are not generally listed anyway.
* Regen customized.dat for base.pm changes againSteve Hay2016-10-121-1/+1
|
* Regen customized.dat for base.pm changesSteve Hay2016-10-121-1/+1
|
* Update customized.dat entry for base.pmSteve Hay2016-08-101-1/+1
| | | | | (This was missed when cherry-picking base.pm changes from blead since it's currently not listed in blead's customized.dat!)
View Lorry Controller Status