With FEATURE_VI_REGEX_SEARCH enabled backward searches don't work.
This is problematic on distros that enable regexes, such as Tiny
Core Linux and Fedora.
When calling GNU re_search() with a negative range parameter
(indicating a backward search) the start offset must be set to
the end of the area being searched.
The return value of re_search() is the offset of the matched pattern
from the start of the area being searched. For a successful search
(positive return value) char_search() can return the pointer to
the start of the area plus the offset.
FEATURE_VI_REGEX_SEARCH isn't enabled by default but when it is:
function old new delta
char_search 256 247 -9
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-9) Total: -9 bytes
Signed-off-by: Andrey Dobrovolsky <andrey.dobrovolsky.odessa@gmail.com>
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Should we validate that PID is a number for "taskset -ap PID"?
We don't actually need it, and pathological input like
"../../DIR_WITH_LOTS_OF_PIDS" can only cause "taskset"ing
of many pids. Which is something user can do anyway.
function old new delta
taskset_main 190 181 -9
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Accepting nonsense like "--4", and even "-- -4" is confusing.
function old new delta
parse_expr 917 938 +21
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Was:
xxd: FILE: No such file or directory
xxd: FILE: Bad file descriptor
function old new delta
next 276 278 +2
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
If the motion command used to define the range of a change, yank or
delete fails the whole command should be rejected. BusyBox vi already
handled failed searches in these circumstances. Add some more cases:
- non-existent mark: d'x
- movement beyond end of file: c99999+ or 99999<<
This is implemented using a global variable which is set when a command
error is detected. Unlike the case of motion within a line it's
insufficient to check that the motion command doesn't move the cursor:
this fails to process 'LyL' correctly, for example, as the second 'L'
doesn't move the cursor.
function old new delta
indicate_error 75 82 +7
find_range 686 692 +6
do_cmd 4851 4852 +1
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 3/0 up/down: 14/0) Total: 14 bytes
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
In traditional vi and vim line motion commands ('+'/'-'/'j'/'k')
fail if the movement would exceed the bounds of the file. BusyBox vi
allowed such commands to succeed, leaving the cursor on the first or
last character of the file.
Make BusyBox vi work like vi/vim.
For the 'G'/'H'/'L' commands traditional vi treats an out of bounds
result as an error, vim doesn't. BusyBox vi behaves like vim, both
before and after this patch.
function old new delta
do_cmd 4785 4851 +66
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 1/0 up/down: 66/0) Total: 66 bytes
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
When ESC is entered to leave insert mode any autoindent should only
be removed if there's no content beyond the indent. This may be the
case if a line has been split by entering insert mode and then
entering a CR.
Add a check to ensure there's only a newline after the indent.
function old new delta
char_insert 912 929 +17
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 1/0 up/down: 17/0) Total: 17 bytes
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Second reference to a field reallocs/moves Fields[] array, but first ref
still tries to use the element where it was before move.
function old new delta
fsrealloc 94 106 +12
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Testcase:
21 01 01 00 00 00 00 00 e7 01 01 01 ef 00 df b6
00 17 02 10 11 0f ff 00 16 00 00
Unfortunately, the bug is not reliably causing a segfault,
the behavior depends on what's in memory before the buffer.
function old new delta
unpack_lzma_stream 2762 2768 +6
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
...and we did not error-check it, and this is the only use of it:
function old new delta
inet_addr 37 - -37
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Even though it is _meant to be_ an IP address, in the wild servers sometimes
give bogus server ids, like 1.1.1.1
function old new delta
udhcpc_main 2551 2542 -9
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
The default tabstop value should be set during early start up,
not reset for each new file.
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
When no line number is specified ':read' should place the inserted
text after the current line, not before.
This used to be correct but was broken when commit 0c42a6b07
(vi: fix empty line range regression) revealed a bug in commit
7a8ceb4eb (vi: changes to line addresses for colon commands).
function old new delta
colon 3960 3952 -8
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-8) Total: -8 bytes
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
