Re: [PATCH] Fix #87 - Segfault fault when autocompleting after ">" in, "!> ."

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Mon, Nov 28, 2016 at 5:06 AM, Raphaël Jakse <raphael.jakse@xxxxxxx> wrote:
>
> Here is a patch that works around this bug by checking whether s is null in
> the get_comp_string function (zle_tricky.c) before a code that seems to
> assume that s is not null.

Thanks for calling our attention to this.

The actual problem seems to be that the code assumed ztrdup(NULL)
would return empty string, when in fact it returns NULL:

diff --git a/Src/Zle/zle_tricky.c b/Src/Zle/zle_tricky.c
index c8d3bb3..d636373 100644
--- a/Src/Zle/zle_tricky.c
+++ b/Src/Zle/zle_tricky.c
@@ -1464,7 +1464,10 @@ get_comp_string(void)
        t0 = STRING;
     } else if (t0 == STRING || t0 == TYPESET) {
        /* We found a simple string. */
-       s = ztrdup(clwords[clwpos]);
+       if (clwords[clwpos])
+           s = ztrdup(clwords[clwpos]);
+       else
+           s = ztrdup("");
     } else if (t0 == ENVSTRING) {
        char sav;
        /* The cursor was inside a parameter assignment. */

The reason "we found a simple string" is because the completion system
inserts a phantom "x" at the cursor to be sure it can split the
current word into before/after substrings, so the parser is actually
handed "!>x" and asked for the token at "x".  The "x" is then removed
again, and clwpos (command line word position) ends up pointing at the
null terminator of the clwords array.

> It is unclear to me how to send a patch for zsh so please let me know if
> something is wrong or if additional steps are necessary to apply this patch.

What you did is fine, though we prefer that the attachment be of type
"text/plain" (which usually means you should not use ".patch" or
".diff" as the file name extension).