| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
historysearchforward advanced zlecs instead of histpos
(historysearchbackward already correctly uses CCRIGHTPOS(histpos)
ST is actually 0x9c per ctlseqs.txt
ESC \
String Terminator (ST is 0x9c).
fix plenty of indexing confusion with prompt_markers(), it was never
returning pre because markers did not include it. constants were
compared against the wrong variable, or using the wrong hardcoded index
(and those indices also changed now that pre is in markers).
in bracketedstring, the imeta(next) branch writes two bytes to pbuf,
make sure they both fit.
only reallocate once in sizeline, and correct the comment for
stringaszleline, though I don't think anyone will do that.
putreplaceselection used a stale buffer in the following scenario:
% blah
set region to bl with cursor on a, hit ctrl-k, then invoke
put-replace-selection via alt-x or bind it in advance.
==10588== Invalid read of size 2
==10588== by 0x6588FAA: pastebuf (zle_misc.c:597)
==10588== by 0x65895A6: putreplaceselection (zle_misc.c:720)
==10588== Address 0x6219550 is 0 bytes inside a block of size 16 free'd
==10588== at 0x483C17B: free (vgpreload_memcheck-amd64-linux.so)
==10588== by 0x65A347A: cuttext (zle_utils.c:1023)
==10588== Block was alloc'd at
==10588== at 0x483E82F: realloc (vgpreload_memcheck-amd64-linux.so)
==10588== by 0x65A34E8: cuttext (zle_utils.c:1028)
also set clear so the stringaszleline allocation is freed in the same
function, and fix the same leak in viputbefore and viputafter.
fix out of bounds access in vimatchbracket
==11986== Invalid read of size 4
==11986== at 0x658D14C: vimatchbracket (zle_move.c:645)
fix out of bounds access in backwardmetafiedchar, this one won't cause a
valgrind warning because the memory is owned by us.
fix two separate leaks (impressive) when assigning to $registers special zle parameter
==16615== 2,799,972 bytes in 99,999 blocks are definitely lost in loss record 631 of 631
==16615== at 0x48397B5: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==16615== by 0x473836: zalloc (mem.c:966)
==16615== by 0x65A1EEC: stringaszleline (zle_utils.c:440)
==16615== by 0x658EF17: set_register (zle_params.c:775)
==16615== 599,988 bytes in 99,998 blocks are definitely lost in loss record 630 of 631
==16615== at 0x48397B5: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==16615== by 0x473836: zalloc (mem.c:966)
==16615== by 0x4AA101: ztrdup (string.c:68)
==16615== by 0x435536: addvars (exec.c:2604)
don't crash on 'bindkey x foo; zle -l foo'
==21910== Process terminating with default action of signal 11 (SIGSEGV)
==21910== Access not within mapped region at address 0x0
==21910== at 0x6597303: bin_zle_list (zle_thingy.c:406)
==21910== by 0x6597229: bin_zle (zle_thingy.c:388)
restore keymap and zmod when erroring out of bin_zle_call
inststrlen used the wrong len to advance zlecs which would cause it to
advance way past the end of zleline. fortunately this function is never
called with zlemetaline == NULL.
fix expand-cmd-path to not just move the cursor an arbitrary
amount forward, and convert the indices from zlemetaline to zleline.
bangq in magicspace could be used after zleline was realloc()d,
calculate the offset before calling selfinsert()
the memo field wasn't always freed for region highlights
vi-indent was skipping the last line for 4+ line ranges
vi-unindent buffer overrun
==3900== Conditional jump or move depends on uninitialised value(s)
==3900== at 0x65A3CE6: findeol (zle_utils.c:1180)
==3900== by 0x65A6E01: viunindent (zle_vi.c:880)
break the loop on eof in vi-caps-lock-panic, though we do exit anyway
when the terminal closes
off by one in condition in vi-backward-word-end, this only prevented us
moving to the start of the buffer if we were on the second character
exactly.
seq in cursor_form() was one byte too small to fit the nul terminator:
zsh% zle_cursorform=( edit:steady,color=\#abcdef )
Breakpoint 1, cursor_form () at termquery.c:987
987 if (s - seq)
(gdb) p s - seq
$1 = 31
fix negation of h-3 in setmstatus. this was very noticable in interactive
menu selection if you typed a long string. the entire string would be
replaced by three dots instead of just the start of it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Coverity CID 1692322 in Src/glob.c:
i'm pretty sure this is a false positive so add a debug message just in case
Coverity CID 1500752 in Src/Zle/compresult.c:
remove unused assignment that also reads uninitialized pointer p
And two that were just near other things it complained about
Src/utils.c:
Warn if maildir disappeared from under us
Src/Modules/system.c:
stray \n in zwarn message
Src/subst.c:
Use DIGBUFSIZE for buf holding digits
This one would be a little hard to overflow in practice, you'd need a
parameter at least 100000000000000 characters long, which is 100TB.
|
| |
|
|
| |
I think this is not actually a problem but might as well initialize it.
|
| | |
|
| |
|
|
|
| |
I think we can only get non-ascii chars here if the terminal is actively
being malicious, but doesn't hurt to be correct.
|
| |
|
|
|
| |
This could happen if a terminal replies with a bg value we don't know
about.
|
| |
|
|
|
|
|
|
| |
For non-ascii bytes, we passed negative values around,
resulting in:
write(10, "/code/zsh/%FFFFFFC3%FFFFFFA5", 54) = 54
With the change, we get the more reasonable:
write(10, "/code/zsh/%C3%A5", 42) = 42
|
| |
|
|
|
|
| |
This might have caused a valgrind warning when zlecs == zlell
and zleline[zlell] was uninitialized, but I didn't actually get any. It
still makes sense to move this variable into the else branch, though.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
One of these, not sure which, triggered a warning from valgrind:
==31255== Conditional jump or move depends on uninitialised value(s)
==31255== at 0x617D854: doinsert (zle_misc.c:51)
==31255== by 0x617DA8D: selfinsert (zle_misc.c:124)
==31255== by 0x617A51E: execzlefunc (zle_main.c:1492)
==31255== by 0x6179357: zlecore (zle_main.c:1152)
==31255== by 0x6179DFB: zleread (zle_main.c:1367)
==31255== by 0x617D05A: zle_main_entry (zle_main.c:2148)
==31255== by 0x45CD6B: zleentry (init.c:1779)
==31255== by 0x45E0B0: inputline (input.c:421)
==31255== by 0x45DEFE: ingetc (input.c:354)
==31255== by 0x44FD6C: ihgetc (hist.c:420)
==31255== by 0x46889F: gettok (lex.c:622)
==31255== by 0x467F2E: zshlex (lex.c:275)
That code just does an innocuous zleline[zlecs] access, which many other
places also do.
|
| |
|
|
|
| |
Spotted this while looking for zlell assignments, I'm not sure exactly
what the consequence was but presumably things sometimes went wrong.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
The sequence isn't consumed so gets printed and then quickly erased.
macOS conveniently sets TERM_PROGRAM in the environment so this can be
detected.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
allow mixing of colours
|
| |
|
|
|
|
|
| |
Given keybindings which have other vi bindings as a prefix, we don't
apply KEYTIMEOUT because we've got to wait for a movement command
anyway. This delays running the vi widget so the cursor change was not
happening.
|
| |
|
|
| |
braces
|
| |
|
|
|
|
| |
addresses -Wmaybe-uninitialized and (spurious) -Wformat-overflow warnings
omitted the change for zle_refresh.c since it was caught in w/54036
|
| |
|
|
| |
and locale combination
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
.term.querywait variable
Also clarify documentation and include fewer of the new extensions by default
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
When zsh is run with -o vi / -o emacs, instead of loading ZLE to force
the change, only record the option state. Then when ZLE starts, the vi
option determines the default keymap.
|
| |
|
|
|
| |
They are likely to be terminal query responses not keys. If they do match a
keybinding that's not affected. Also does likewise for certain CSI sequences.
|
| |
|
|
| |
(fix for segfault)
|
| |
|
|
| |
Also make use of the dupstring_wlen() variant in more places to avoid a strlen()
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
and WATCHFMT
|
| | |
|
| | |
|
| |
|
|
|
| |
This provide control over the precedence of highlighting where
different regions overlap.
|