Added comments raising questions about possible updates to channel

drivers on Windows.

3 files changed, 17 insertions, 0 deletions

diff --git a/win/tclWinChan.c b/win/tclWinChan.c
index c63aaa7..48acacb 100644
--- a/win/tclWinChan.c
+++ b/win/tclWinChan.c
@@ -662,6 +662,10 @@ FileInputProc(
     *errorCode = 0;
 
     /*
+     * TODO: This comment appears to be out of date.  We *do* have a
+     * console driver, over in tclWinConsole.c.  After some Windows
+     * developer confirms, this comment should be revised.
+     *
      * Note that we will block on reads from a console buffer until a full
      * line has been entered. The only way I know of to get around this is to
      * write a console driver. We should probably do this at some point, but
diff --git a/win/tclWinConsole.c b/win/tclWinConsole.c
index 0ec22c5..6630083 100644
--- a/win/tclWinConsole.c
+++ b/win/tclWinConsole.c
@@ -756,6 +756,13 @@ ConsoleInputProc(
 
     if (ReadConsoleBytes(infoPtr->handle, (LPVOID) buf, (DWORD) bufSize,
 	    &count) == TRUE) {
+	/*
+	 * TODO: This potentially writes beyond the limits specified
+	 * by the caller.  In practice this is harmless, since all writes
+	 * are into ChannelBuffers, and those have padding, but still
+	 * ought to remove this, unless some Windows wizard can give
+	 * a reason not to.  
+	 */
 	buf[count] = '\0';
 	return count;
     }
diff --git a/win/tclWinPipe.c b/win/tclWinPipe.c
index 77fc776..a9eec6d 100644
--- a/win/tclWinPipe.c
+++ b/win/tclWinPipe.c
@@ -82,6 +82,12 @@ static ProcInfo *procList;
 #define PIPE_EXTRABYTE	(1<<3)	/* The reader thread has consumed one byte. */
 
 /*
+ * TODO: It appears the whole EXTRABYTE machinery is in place to support
+ * outdated Win 95 systems.  If this can be confirmed, much code can be
+ * deleted.
+ */
+
+/*
  * This structure describes per-instance data for a pipe based channel.
  */