From f41b9c6304e7ba5e3fcda68863393e3330f3c387 Mon Sep 17 00:00:00 2001 From: Simon Tatham Date: Tue, 10 Feb 2004 19:07:45 +0000 Subject: [PATCH] Jacob reports a segfault when using HTTP proxying under Minefield. 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. [originally from svn r3844] --- proxy.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/proxy.c b/proxy.c index d970b2bf..dd5c428c 100644 --- a/proxy.c +++ b/proxy.c @@ -590,8 +590,14 @@ int proxy_http_negotiate (Proxy_Socket p, int change) /* 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) {