23.0.50; ^D inserted into network streams

23.0.50; ^D inserted into network streams

[Magnus Henoch]

When sending binary data (in particular, data where newlines are more
than 250 bytes apart) on a network connection, Emacs sometimes inserts
^D bytes.  This seems to be a heisenbug; it doesn't always happen.

A test case:

;; Make a netcat receiver: nc -l -p 10000 >/tmp/output

(defun test-stream-pollution (file host port)
  (interactive 
   (list
    (read-file-name "Send file: " nil nil t)
    (read-string "Connect to host (default `127.0.0.1'): "
		 nil nil "127.0.0.1")
    (read-number "Connect to port: " 10000)))
  (let* ((conn (open-network-stream "pollution" nil host port)))
    (set-process-coding-system conn 'binary 'binary)
    (with-temp-buffer 
      (insert-file-contents-literally file)
      (message "Sending file...")
      (process-send-region conn (point-min) (point-max))
      (message "Sending file...done"))
    (delete-process conn)))

If the file sent is binary by the above definition, the two copies of
the file will sometimes differ in that a ^D is inserted every 250th
byte.

The following patch seems to fix the problem.  Is it the proper fix?
Should it be applied to both trunk and branch(es)?  Do more fields need
initialization?

2007-12-02  Magnus Henoch  <mange@freemail.hu>

	* process.c (make_process): Initialize pty_flag to 0.

--- a/src/process.c
+++ b/src/process.c
@@ -634,6 +634,7 @@ make_process (name)
   p->raw_status_new = 0;
   p->status = Qrun;
   p->mark = Fmake_marker ();
+  p->pty_flag = 0;
 
 #ifdef ADAPTIVE_READ_BUFFERING
   p->adaptive_read_buffering = 0;




In GNU Emacs 23.0.50.2 (powerpc-unknown-netbsd4.99.36, GTK+ Version 2.12.0)
 of 2007-12-02 on zemdatav
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: nil
  locale-coding-system: nil
  default-enable-multibyte-characters: t

Major mode: C/l

Minor modes in effect:
  display-time-mode: t
  jabber-activity-mode: t
  jabber-mode-line-mode: t
  iswitchb-mode: t
  icomplete-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t
  abbrev-mode: t

Re: 23.0.50; ^D inserted into network streams

[Richard Stallman]

I think this is a feature that was designed to get out of a state
where a subprocess is waiting for a line of input and the kernel won't
give it any input until it gets a whole line from Emacs.

I do not know if that problem can still occur in modern systems.

Your patch looks correct to me.  I installed it in Emacs 22.
Thanks.

Re: 23.0.50; ^D inserted into network streams

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 03 Dec 2007 01:10:56 -0500, Richard Stallman <rms@gnu.org> said:

> I think this is a feature that was designed to get out of a state
> where a subprocess is waiting for a line of input and the kernel
> won't give it any input until it gets a whole line from Emacs.

> I do not know if that problem can still occur in modern systems.

> Your patch looks correct to me.  I installed it in Emacs 22.
> Thanks.

I've just changed the initialization value from 0 to Qnil in the
EMACS_22_BASE branch, because the `pty_flag' member in Emacs 22 is not
a bit field as in Emacs 23, but a Lisp object.

Miles, please do not propagate the following change to the trunk at
the merger next time.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

--- process.c	2007/12/03 00:40:41	1.512.2.8
+++ process.c	2007/12/24 05:25:42	1.512.2.9
@@ -626,7 +626,7 @@
   XSETFASTINT (p->tick, 0);
   XSETFASTINT (p->update_tick, 0);
   p->pid = 0;
-  p->pty_flag = 0;
+  p->pty_flag = Qnil;
   p->raw_status_new = 0;
   p->status = Qrun;
   p->mark = Fmake_marker ();

Re: 23.0.50; ^D inserted into network streams

[Richard Stallman]

    Miles, please do not propagate the following change to the trunk at
    the merger next time.

I have an idea.  You could rearrange the code in the trunk
somewhat, so that the Emacs 22 patch would not merge in cleanly,
and add a comment in Emacs 22 saying "don't merge this into Emacs 23".
Together, they will be a reminder that would be hard to miss.