It appears that this is because Visual C's sscanf works by first
calling strlen to get the length of the string, so that its internal
read-character routine can be sure of never overrunning the buffer.
Quite why the internal read-char routine can't detect \0 _itself_
rather than having to have it found for it in advance I have no
idea. Sigh.
git-svn-id: svn://svn.tartarus.org/sgt/putty@3844
cda61777-01e9-0310-a592-
d414129be87e
/* get the status line */
len = bufchain_size(&p->pending_input_data);
assert(len > 0); /* or we wouldn't be here */
- data = snewn(len, char);
+ data = snewn(len+1, char);
bufchain_fetch(&p->pending_input_data, data, len);
+ /*
+ * We must NUL-terminate this data, because Windows
+ * sscanf appears to require a NUL at the end of the
+ * string because it strlens it _first_. Sigh.
+ */
+ data[len] = '\0';
eol = get_line_end(data, len);
if (eol < 0) {