Consistently use a single notation to refer to SSH protocol versions, as
[u/mdw/putty] / terminal.c
index 1e9fb37..eaaa04d 100644 (file)
@@ -1017,6 +1017,21 @@ static termline *lineptr(Terminal *term, int y, int lineno, int screen)
     }
 
     /* We assume that we don't screw up and retrieve something out of range. */
+    if (line == NULL) {
+       fatalbox("line==NULL in terminal.c\n"
+                "lineno=%d y=%d w=%d h=%d\n"
+                "count(scrollback=%p)=%d\n"
+                "count(screen=%p)=%d\n"
+                "count(alt=%p)=%d alt_sblines=%d\n"
+                "whichtree=%p treeindex=%d\n\n"
+                "Please contact <putty@projects.tartarus.org> "
+                "and pass on the above information.",
+                lineno, y, term->cols, term->rows,
+                term->scrollback, count234(term->scrollback),
+                term->screen, count234(term->screen),
+                term->alt_screen, count234(term->alt_screen), term->alt_sblines,
+                whichtree, treeindex);
+    }
     assert(line != NULL);
 
     resizeline(term, line, term->cols);
@@ -6216,13 +6231,13 @@ int term_data(Terminal *term, int is_stderr, const char *data, int len)
      * the remote side needing to wait until term_out() has cleared
      * a backlog.
      *
-     * This is a slightly suboptimal way to deal with SSH2 - in
+     * This is a slightly suboptimal way to deal with SSH-2 - in
      * principle, the window mechanism would allow us to continue
      * to accept data on forwarded ports and X connections even
      * while the terminal processing was going slowly - but we
      * can't do the 100% right thing without moving the terminal
      * processing into a separate thread, and that might hurt
-     * portability. So we manage stdout buffering the old SSH1 way:
+     * portability. So we manage stdout buffering the old SSH-1 way:
      * if the terminal processing goes slowly, the whole SSH
      * connection stops accepting data until it's ready.
      *