From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 15 05:07:50 2012 Received: (at submit) by debbugs.gnu.org; 15 Feb 2012 10:07:50 +0000 Received: from localhost ([127.0.0.1]:41077 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RxbmA-0000V5-DQ for submit@debbugs.gnu.org; Wed, 15 Feb 2012 05:07:50 -0500 Received: from eggs.gnu.org ([140.186.70.92]:43914) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Rxbm7-0000Uu-Ns for submit@debbugs.gnu.org; Wed, 15 Feb 2012 05:07:48 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RxbkN-0005Le-Le for submit@debbugs.gnu.org; Wed, 15 Feb 2012 05:06:01 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([140.186.70.17]:59482) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RxbkN-0005LZ-Iw for submit@debbugs.gnu.org; Wed, 15 Feb 2012 05:05:59 -0500 Received: from eggs.gnu.org ([140.186.70.92]:52094) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RxbkH-0000Nr-VY for bug-gnu-emacs@gnu.org; Wed, 15 Feb 2012 05:05:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RxbkG-0005Kd-Ne for bug-gnu-emacs@gnu.org; Wed, 15 Feb 2012 05:05:53 -0500 Received: from mail1-relais-roc.national.inria.fr ([192.134.164.82]:15251) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RxbkG-0005K8-J6 for bug-gnu-emacs@gnu.org; Wed, 15 Feb 2012 05:05:52 -0500 X-IronPort-AV: E=Sophos;i="4.73,422,1325458800"; d="scan'208";a="144329512" Received: from chercheurs2-247.saclay.inria.fr (HELO [193.55.250.247]) ([193.55.250.247]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 15 Feb 2012 11:05:49 +0100 Message-ID: <4F3B837D.4050506@inria.fr> Date: Wed, 15 Feb 2012 11:05:49 +0100 From: Tiphaine Turpin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111109 Thunderbird/3.1.16 MIME-Version: 1.0 To: bug-gnu-emacs@gnu.org Subject: counterintuitive results with process-send-string Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.17 X-Spam-Score: -4.2 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.2 (----) Hello, I realized a strange behavior of process-send-string when writing to a socket, and I am wondering whether is is expected or not, and how to live with it. Here is a very short extract from my code (exact code, no simplification): (message "sending command %s" c) (process-send-string connection (concat request-start "\n" c "\n" end-of-message "\n")) (message "command sent: %s" c) and an extract of the resulting *Messages* (I have replaced the real "command" contents by timestamps): sending command 1 sending command 2 command sent: 2 sending command 3 command sent: 3 command sent: 1 The other end of the socket connection receives the messages in the order 2, 3, 1, i.e., the same as indicated by "comment sent" debug messages. It seems that process-send-string,although it is blocking (until sent data is acknowledged), may allow execution of other code (which in this case calls process-send-string again). This seems to be allowed by its specification: "Output from processes can arrive in between bunches.", except that in my setting, I am almost sure than no input can be available at this moment, at least from this connection. In fact, the calls to process-send-string are initiated by after-modify hooks, originating from a single user command (which performs several modifications). But what is really annoying, is that the inner call to process-send-string takes priority on the pending one: the second message is actually sent before the first, while I would expect the messages to be queued in the right order. So, I would very much appreciate an opinion on whether this semantics is appropriate. Furthermore, any hint about working around this behavior will be welcome, as I don't know what would be the equivalent of "mutexes" in the absence of threads :-\ . Finally, it won't be easy to isolate a reproducible test-case (this is about implementing fontification with an external tool), but I can try if this observed behavior seems really impossible from the implementation of process-send-string. Regards, Tiphaine Turpin From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 15 06:02:17 2012 Received: (at 10815) by debbugs.gnu.org; 15 Feb 2012 11:02:17 +0000 Received: from localhost ([127.0.0.1]:41121 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Rxccm-0001kw-2u for submit@debbugs.gnu.org; Wed, 15 Feb 2012 06:02:17 -0500 Received: from mail-out.m-online.net ([212.18.0.10]:57783) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Rxcce-0001ke-6y for 10815@debbugs.gnu.org; Wed, 15 Feb 2012 06:02:09 -0500 Received: from frontend1.mail.m-online.net (frontend1.mail.intern.m-online.net [192.168.8.180]) by mail-out.m-online.net (Postfix) with ESMTP id 3853018002EB; Wed, 15 Feb 2012 12:00:21 +0100 (CET) X-Auth-Info: jP0oq36JbKkHxZA0M/X36/YQD9sMaH9216upu3RtPcY= Received: from igel.home (ppp-93-104-147-89.dynamic.mnet-online.de [93.104.147.89]) by mail.mnet-online.de (Postfix) with ESMTPA id 626781C00123; Wed, 15 Feb 2012 12:00:21 +0100 (CET) Received: by igel.home (Postfix, from userid 501) id A63DBCA29E; Wed, 15 Feb 2012 12:00:20 +0100 (CET) From: Andreas Schwab To: Tiphaine Turpin Subject: Re: bug#10815: counterintuitive results with process-send-string References: <4F3B837D.4050506@inria.fr> X-Yow: I know how to do SPECIAL EFFECTS!! Date: Wed, 15 Feb 2012 12:00:20 +0100 In-Reply-To: <4F3B837D.4050506@inria.fr> (Tiphaine Turpin's message of "Wed, 15 Feb 2012 11:05:49 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.93 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 10815 Cc: 10815@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) Tiphaine Turpin writes: > It seems that process-send-string,although it is blocking (until sent data > is acknowledged), may allow execution of other code (which in this case > calls process-send-string again). This seems to be allowed by its > specification: "Output from processes can arrive in between bunches.", > except that in my setting, I am almost sure than no input can be available > at this moment, at least from this connection. In fact, the calls to > process-send-string are initiated by after-modify hooks, originating from > a single user command (which performs several modifications). wait_reading_process_output can run timers. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 23 00:08:39 2012 Received: (at 10815) by debbugs.gnu.org; 23 Feb 2012 05:08:39 +0000 Received: from localhost ([127.0.0.1]:51773 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1S0Qv0-0005eU-Mc for submit@debbugs.gnu.org; Thu, 23 Feb 2012 00:08:39 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.183]:34002) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1S0Quy-0005e8-Tp; Thu, 23 Feb 2012 00:08:37 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAOPIRU9Ld/XJ/2dsb2JhbABEsliBCIFzAQEEAVYjBQsLNBIUGA0kiBS4S40KYRcGCoUXCoQbBIhPmxmEWw X-IronPort-AV: E=Sophos;i="4.73,468,1325480400"; d="scan'208";a="164253285" Received: from 75-119-245-201.dsl.teksavvy.com (HELO pastel.home) ([75.119.245.201]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 23 Feb 2012 00:05:43 -0500 Received: by pastel.home (Postfix, from userid 20848) id 3D5D559173; Thu, 23 Feb 2012 00:05:43 -0500 (EST) From: Stefan Monnier To: Tiphaine Turpin Subject: Re: bug#10815: counterintuitive results with process-send-string Message-ID: References: <4F3B837D.4050506@inria.fr> Date: Thu, 23 Feb 2012 00:05:43 -0500 In-Reply-To: <4F3B837D.4050506@inria.fr> (Tiphaine Turpin's message of "Wed, 15 Feb 2012 11:05:49 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.93 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 10815 Cc: 10815@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) severity 10815 important thanks > Here is a very short extract from my code (exact code, no simplification): > (message "sending command %s" c) > (process-send-string connection > (concat request-start "\n" c "\n" end-of-message > "\n")) > (message "command sent: %s" c) > and an extract of the resulting *Messages* (I have replaced the real > "command" contents by timestamps): > sending command 1 > sending command 2 > command sent: 2 > sending command 3 > command sent: 3 > command sent: 1 This output is not a problem in itself, it can be explained as follows: - (message "sending command %s" 1) - (process-send-string connection .... 1) - after sending the command we check timers and process filters; turns out we received an answer from the process so we run the filter. - (message "sending command %s" 2) - (process-send-string connection .... 2) - (message "command sent: %s" 2) - before returning from process-send-string, we check timers and filters once more and find another answer, so we run the filter again. - (message "sending command %s" 3) - (process-send-string connection .... 3) - (message "command sent: %s" 3) - finally the timers and filters seem all processed, we can return. - (message "command sent: %s" 1) > The other end of the socket connection receives the messages in the order 2, > 3, 1, i.e., the same as indicated by "comment sent" debug messages. That is more problematic. I haven't looked enough at the code to see exactly why it happens, but I agree it's undesirable. > It seems that process-send-string,although it is blocking (until sent data > is acknowledged), may allow execution of other code (which in this case > calls process-send-string again). This seems to be allowed by its > specification: "Output from processes can arrive in between bunches.", Indeed, but it doesn't justify the kind of out-of-order-sending you're seeing (although it may explain it). > except that in my setting, I am almost sure than no input can be available > at this moment, at least from this connection. Are you sure: consider the case where the OS forces Emacs to yield right after sending the bytes, such that the other process gets to reply before Emacs finishes the process-send-string? Of course, rather than process filters, the culprit might be a timer. > In fact, the calls to process-send-string are initiated by > after-modify hooks, originating from a single user command (which > performs several modifications). Can they also be triggered from timers? I.e. is there some timer code modifying the buffer? Or does the process-filter itself modify the buffer (seems unlikely since it would lead to inf-loops)? > But what is really annoying, is that the inner call to process-send-string > takes priority on the pending one: the second message is actually sent > before the first, while I would expect the messages to be queued in the > right order. Yes, that seems to be a bug/misfeature. Stefan From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 26 11:58:14 2012 Received: (at 10815) by debbugs.gnu.org; 26 Mar 2012 15:58:14 +0000 Received: from localhost ([127.0.0.1]:39846 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SCCJA-0001k6-KX for submit@debbugs.gnu.org; Mon, 26 Mar 2012 11:58:14 -0400 Received: from mail-yw0-f44.google.com ([209.85.213.44]:54852) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SCCJ5-0001js-Q0 for 10815@debbugs.gnu.org; Mon, 26 Mar 2012 11:58:10 -0400 Received: by yhkk25 with SMTP id k25so3790212yhk.3 for <10815@debbugs.gnu.org>; Mon, 26 Mar 2012 08:26:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=3nyOpSr7NGf4G+pMGMAY3NQv6M4C4BgAQZtwUjBgO+0=; b=xAJwIOFcW9WVJ6uOtLMkkuRCYd2+WtQ+z2QdT6PD8HqaZT5uIWEhQivrqux4OUERb8 lqBhezRhYuv2zY8iWGB6bnnUEA3jh/fWasCyst1IgQ/N/O1qheHDQ/VOCRwuFTJ7iinl CYDXRp2Se/IyCLfEERWE9fgonPiztcgehkKCtOdZuX6neL5HtY01locXI/WhdJsdDmVq oyIEGdAkLcmbwzBf1OCuUwonAzGhMzCdmg+tREFaobx7b3L+Vw0y1rHPGUrNM1bvXjnM GDG67547ivfR1hiMr9vhSmpYN+dPc2wiEl+jxbOYS4SYhKDcm1vhxD2gvvtk0Iu/96t3 G72w== MIME-Version: 1.0 Received: by 10.236.154.232 with SMTP id h68mr23205735yhk.51.1332775616813; Mon, 26 Mar 2012 08:26:56 -0700 (PDT) Received: by 10.236.25.39 with HTTP; Mon, 26 Mar 2012 08:26:56 -0700 (PDT) Date: Mon, 26 Mar 2012 17:26:56 +0200 Message-ID: Subject: Re: #10815 counterintuitive results with process-send-string From: Troels Nielsen To: 10815@debbugs.gnu.org Content-Type: multipart/mixed; boundary=20cf303dd29e349ce904bc270121 X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 10815 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) --20cf303dd29e349ce904bc270121 Content-Type: text/plain; charset=ISO-8859-1 Hi all I've been looking into this problem and have succeed in reproducing the issue: Just compile echo-server.c and execute it, and then eval-buffer write-queue-issue.el. Messages will be seen to be sent from emacs and arrive in different order. I have a proposed patch, which fixes the ordering. It seems that the best way to ensure that everything is sent in the right order, is to add a write queue keeping track of data that has not been sent and sending the unsent data before any new data is attempted. It will not ensure that send_process 1 will return before send_process 2 is executed, but it will ensure that the data in send_process 1 will be sent before the data in send_process 2. And it will certainly ensure that not half of the data of send_process 1 is sent, then send_process's 2 data and then the rest of send_process 1's data, which is kind of catastrophic. In addition I spotted another possible bug which could be serious when a buffer object is used as an argument: The code currently: object is a buffer, that won't need encoding until (len == 0) { attempt write and get error if (errno == EAGAIN etc.) { ... if (BUFFERP (object)) offset = BUF_PTR_BYTE_POS (XBUFFER (object), (unsigned char *) buf); wait_reading_process_output if (BUFFERP (object)) buf = (char *) BUF_BYTE_ADDRESS (XBUFFER (object), offset); }} Now, as far as I can see, we have no guarantee that the buffer object has not changed while wait_reading_process_output is called, which in and of itself is kind of bad. But this/len has not been updated, and if buffer has been shortened (or maybe killed (?)) we may very well be in for a segmentation fault. In the new code this possible problem have been fixed by copying the buffer data to be sent into a string, whenever calling wait_reading_process_output. Regards, Troels PS. This is the patch without indent-changes. I attach the patch including new indents: === modified file 'src/process.c' *** src/process.c 2012-03-23 12:23:14 +0000 --- src/process.c 2012-03-26 14:03:27 +0000 *************** make_process (Lisp_Object name) *** 631,636 **** --- 631,637 ---- p->status = Qrun; p->mark = Fmake_marker (); p->kill_without_query = 0; + p->write_queue = Qnil; #ifdef ADAPTIVE_READ_BUFFERING p->adaptive_read_buffering = 0; *************** send_process_trap (int ignore) *** 5366,5371 **** --- 5367,5462 ---- longjmp (send_process_frame, 1); } + /* In send_process, when a write fails temporarily, + wait_reading_process_output is called. + + It may execute user code, for example timers, that sometimes + attempt to write new data to the same process. Data must be ensured + to be sent in the right order, and certainly not be interspersed + half-completed with other writes. + (See bug #10815) + + To amend this problem the process write_queue has been added. + It is a list with each entry having the form: + + (string . (offset . length)) + + where string is a lisp string, offset is the offset into the + string's bytesequence, from where we should begin to send and + length is the number of bytes left to send. + */ + + /* Create a new entry in write_queue, + + input_obj should be a buffer, string or Qt/Qnil + buf is a pointer to the string sequence of the input_obj or a C + string in case of Qt/Qnil + */ + static void + write_queue_push (struct Lisp_Process *p, Lisp_Object input_obj, + const char *buf, int len, int front) + { + EMACS_INT offset; + Lisp_Object entry, obj; + + if (STRINGP (input_obj)) + { + offset = buf - SSDATA (input_obj); + obj = input_obj; + } + else + { + offset = 0; + obj = make_unibyte_string (buf, len); + } + + entry = Fcons (obj, Fcons (make_number (offset), make_number (len))); + + if (front) + p->write_queue = Fcons (entry, p->write_queue); + else + p->write_queue = nconc2 (p->write_queue, Fcons (entry, Qnil)); + } + + static void + write_queue_push_front (struct Lisp_Process *p, Lisp_Object obj, + const char *buf, EMACS_INT len) + { + write_queue_push (p, obj, buf, len, 1); + } + + static void + write_queue_push_back (struct Lisp_Process *p, Lisp_Object obj, + const char *buf, EMACS_INT len) + { + write_queue_push (p, obj, buf, len, 0); + } + + /* remove the first element in process' write_queue and + put its contents in obj, buf and len or return -1 if + write_queue is empty */ + static int + write_queue_pop_front (struct Lisp_Process *p, Lisp_Object *obj, const + char **buf, EMACS_INT *len) { + Lisp_Object entry, offset_length; + EMACS_INT offset; + + if (NILP (p->write_queue)) + return -1; + + entry = XCAR (p->write_queue); + p->write_queue = XCDR (p->write_queue); + + *obj = XCAR (entry); + offset_length = XCDR (entry); + + *len = XINT (XCDR (offset_length)); + offset = XINT (XCAR (offset_length)); + *buf = SDATA (*obj) + offset; + + return 0; + } + /* Send some data to process PROC. BUF is the beginning of the data; LEN is the number of characters. OBJECT is the Lisp object that the data comes from. If OBJECT is *************** send_process_trap (int ignore) *** 5375,5381 **** for encoding before it is sent. This function can evaluate Lisp code and can garbage collect. */ - static void send_process (volatile Lisp_Object proc, const char *volatile buf, volatile EMACS_INT len, volatile Lisp_Object object) --- 5466,5471 ---- *************** send_process (volatile Lisp_Object proc, *** 5384,5394 **** struct Lisp_Process *p = XPROCESS (proc); ssize_t rv; struct coding_system *coding; - struct gcpro gcpro1; void (*volatile old_sigpipe) (int); - GCPRO1 (object); - if (p->raw_status_new) update_status (p); if (! EQ (p->status, Qrun)) --- 5474,5481 ---- *************** send_process (volatile Lisp_Object proc, *** 5500,5521 **** if (!setjmp (send_process_frame)) { p = XPROCESS (proc); /* Repair any setjmp clobbering. */ - process_sent_to = proc; ! while (len > 0) { ! EMACS_INT this = len; ! /* Send this batch, using one or more write calls. */ ! while (this > 0) { EMACS_INT written = 0; int outfd = p->outfd; old_sigpipe = (void (*) (int)) signal (SIGPIPE, send_process_trap); #ifdef DATAGRAM_SOCKETS if (DATAGRAM_CHAN_P (outfd)) { ! rv = sendto (outfd, buf, this, 0, datagram_address[outfd].sa, datagram_address[outfd].len); if (0 <= rv) --- 5587,5626 ---- if (!setjmp (send_process_frame)) { p = XPROCESS (proc); /* Repair any setjmp clobbering. */ process_sent_to = proc; ! ! /* if there is already data in the write_queue, put the new data ! in the back of queue, otherwise just ignore it */ ! if (!NILP (p->write_queue)) ! write_queue_push_back (p, object, buf, len); ! ! /* until NILP (p->write_queue) */ ! do { ! EMACS_INT cur_len; ! const char *cur_buf; ! Lisp_Object cur_object; ! /* if write_queue is empty, just ignore it */ ! if (NILP (p->write_queue)) { + cur_len = len; + cur_buf = buf; + cur_object = object; + } + else + write_queue_pop_front (p, &cur_object, &cur_buf, &cur_len); + + while (cur_len > 0) + { + /* Send this batch, using one or more write calls. */ EMACS_INT written = 0; int outfd = p->outfd; old_sigpipe = (void (*) (int)) signal (SIGPIPE, send_process_trap); #ifdef DATAGRAM_SOCKETS if (DATAGRAM_CHAN_P (outfd)) { ! rv = sendto (outfd, cur_buf, cur_len, 0, datagram_address[outfd].sa, datagram_address[outfd].len); if (0 <= rv) *************** send_process (volatile Lisp_Object proc, *** 5532,5541 **** { #ifdef HAVE_GNUTLS if (p->gnutls_p) ! written = emacs_gnutls_write (p, buf, this); else #endif ! written = emacs_write (outfd, buf, this); rv = (written ? 0 : -1); #ifdef ADAPTIVE_READ_BUFFERING if (p->read_output_delay > 0 --- 5637,5647 ---- { #ifdef HAVE_GNUTLS if (p->gnutls_p) ! written = emacs_gnutls_write (p, cur_buf, cur_len); else #endif ! written = emacs_write (outfd, cur_buf, cur_len); ! rv = (written ? 0 : -1); #ifdef ADAPTIVE_READ_BUFFERING if (p->read_output_delay > 0 *************** send_process (volatile Lisp_Object proc, *** 5590,5624 **** } #endif /* BROKEN_PTY_READ_AFTER_EAGAIN */ ! /* Running filters might relocate buffers or strings. ! Arrange to relocate BUF. */ ! if (BUFFERP (object)) ! offset = BUF_PTR_BYTE_POS (XBUFFER (object), ! (unsigned char *) buf); ! else if (STRINGP (object)) ! offset = buf - SSDATA (object); ! #ifdef EMACS_HAS_USECS wait_reading_process_output (0, 20000, 0, 0, Qnil, NULL, 0); #else wait_reading_process_output (1, 0, 0, 0, Qnil, NULL, 0); #endif ! ! if (BUFFERP (object)) ! buf = (char *) BUF_BYTE_ADDRESS (XBUFFER (object), ! offset); ! else if (STRINGP (object)) ! buf = offset + SSDATA (object); } else /* This is a real error. */ report_file_error ("writing to process", Fcons (proc, Qnil)); } ! buf += written; ! len -= written; ! this -= written; } } } else { --- 5696,5721 ---- } #endif /* BROKEN_PTY_READ_AFTER_EAGAIN */ ! /* Put what we should have written in ! wait_queue */ ! write_queue_push_front (p, cur_object, cur_buf, cur_len); #ifdef EMACS_HAS_USECS wait_reading_process_output (0, 20000, 0, 0, Qnil, NULL, 0); #else wait_reading_process_output (1, 0, 0, 0, Qnil, NULL, 0); #endif ! /* reread queue, to see what is left */ ! break; } else /* This is a real error. */ report_file_error ("writing to process", Fcons (proc, Qnil)); } ! cur_buf += written; ! cur_len -= written; } } + while (!NILP (p->write_queue)); } else { *************** send_process (volatile Lisp_Object proc, *** 5631,5638 **** deactivate_process (proc); error ("SIGPIPE raised on process %s; closed it", SDATA (p->name)); } - - UNGCPRO; } DEFUN ("process-send-region", Fprocess_send_region, Sprocess_send_region, --- 5728,5733 ---- === modified file 'src/process.h' *** src/process.h 2012-01-19 07:21:25 +0000 --- src/process.h 2012-03-25 16:18:18 +0000 *************** struct Lisp_Process *** 77,82 **** --- 77,84 ---- Lisp_Object encode_coding_system; /* Working buffer for encoding. */ Lisp_Object encoding_buf; + /* Queue for storing waiting writes */ + Lisp_Object write_queue; #ifdef HAVE_GNUTLS Lisp_Object gnutls_cred_type; --20cf303dd29e349ce904bc270121 Content-Type: text/x-csrc; charset=US-ASCII; name="echo-server.c" Content-Disposition: attachment; filename="echo-server.c" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h09n9mbg0 I2luY2x1ZGUgPHN0ZGlvLmg+CiNpbmNsdWRlIDxzdGRsaWIuaD4KI2luY2x1ZGUgPHN5cy90eXBl cy5oPgojaW5jbHVkZSA8c3lzL3NvY2tldC5oPgojaW5jbHVkZSA8YXJwYS9pbmV0Lmg+CiNpbmNs dWRlIDxzdHJpbmcuaD4KI2luY2x1ZGUgPHVuaXN0ZC5oPgojaW5jbHVkZSA8ZXJybm8uaD4KI2lu Y2x1ZGUgPHNpZ25hbC5oPgoKdm9sYXRpbGUgaW50IHNlcnZlcnNvY2ssIHNvY2s7Cgp2b2lkIGtp bGxfbWUoaW50IHNpZykgCnsKICBjbG9zZShzZXJ2ZXJzb2NrKTsgY2xvc2Uoc29jayk7CiAgZXhp dCgxKTsKfQoKI2RlZmluZSBQT1JUIDEyMzQ1CgovKiogYmluZHMgdG8gcG9ydCBQT1JUIGFuZCBw cmludHMgZXZlcnl0aGluZyByZWNlaXZlZCB0aGF0IGlzIG5vdCB0aGUgYXNjaWktbGV0dGVyIGEg Ki8KaW50IG1haW4oaW50IGFyZ2MsIGNoYXIgKiphcmd2KSB7IAogIHNpZ25hbChTSUdJTlQsIGtp bGxfbWUpOyAKICBzZXJ2ZXJzb2NrID0gc29ja2V0KFBGX0lORVQsIFNPQ0tfU1RSRUFNLCBJUFBS T1RPX1RDUCk7CgogIGlmIChzZXJ2ZXJzb2NrID09IC0xKSB7IAogICAgcGVycm9yKCJFcnJvciBj cmVhdGluZyBzb2NrZXQiKTsKICAgIGV4aXQoMSk7CiAgfQogIAogIGludCBvbiA9IDE7CiAgaWYg KHNldHNvY2tvcHQoc2VydmVyc29jaywgU09MX1NPQ0tFVCwgU09fUkVVU0VBRERSLCAoY2hhciop Jm9uLCBzaXplb2Yob24pKSA9PSAtMSkgewogICAgcGVycm9yKCJTZXRzb2Nrb3B0Iik7CiAgICBl eGl0KDEpOwogIH0KICAgIAogIHN0cnVjdCBzb2NrYWRkcl9pbiBzZXJ2ZXIgPSB7MH07CiAgc2Vy dmVyLnNpbl9mYW1pbHkgPSBBRl9JTkVUOwogIHNlcnZlci5zaW5fYWRkci5zX2FkZHIgPSBodG9u bChJTkFERFJfQU5ZKTsKICBzZXJ2ZXIuc2luX3BvcnQgPSBodG9ucyhQT1JUKTsKCiAgaWYgKGJp bmQoc2VydmVyc29jaywgKHN0cnVjdCBzb2NrYWRkciAqKSAmc2VydmVyLCBzaXplb2Yoc2VydmVy KSkgPT0gLTEpIHsKICAgIHBlcnJvcigiRXJyb3IgYmluZGluZyBzb2NrZXQiKTsKICAgIGV4aXQo MSk7CiAgfQoKICBpZiAobGlzdGVuKHNlcnZlcnNvY2ssIDIpID09IC0xKSB7CiAgICBwZXJyb3Io Ikxpc3RlbmluZyBmb3IgY29ubmVjdGlvbiIpOwogICAgZXhpdCgxKTsKICB9CiAgCgogIHdoaWxl ICgxKSB7CiAgICBzdHJ1Y3Qgc29ja2FkZHJfaW4gY2xpZW50OwogICAgaW50IHNvY2s7CiAgICB1 bnNpZ25lZCBpbnQgY2xpZW50bGVuID0gc2l6ZW9mKGNsaWVudCk7CgogICAgLyogV2FpdCBmb3Ig Y2xpZW50IGNvbm5lY3Rpb24gKi8KICAgIHNvY2sgPSBhY2NlcHQoc2VydmVyc29jaywgKHN0cnVj dCBzb2NrYWRkciAqKSAmY2xpZW50LCAmY2xpZW50bGVuKTsKICAgIGlmIChzb2NrID09IC0xKSB7 CiAgICAgIHBlcnJvcigiQWNjZXB0aW5nIGNvbm5lY3Rpb24iKTsKICAgICAgZXhpdCgxKTsKICAg IH0KICAgIAogICAgaW50IG47CiAgICBkbyB7CiAgICAgIHNsZWVwKDEpOwogICAgICBjaGFyIGJ1 ZlsyMDAwMV07CiAgICAgIG4gPSByZWN2KHNvY2ssIGJ1ZiwgMjAwMDAsIDApOwogICAgICBpZiAo biA9PSAtMSkgewogICAgICAgIHBlcnJvcigiRmFpbGVkLi4uIik7CiAgICAgICAgaWYgKCEoZXJy bm8gPT0gRUlOVFIgfHwgZXJybm8gPT0gRUFHQUlOIHx8IGVycm5vID09IEVXT1VMREJMT0NLKSkg CiAgICAgICAgICBicmVhazsKICAgICAgfSAKICAgICAgaW50IGk7CiAgICAgIAogICAgICBmb3Ig KGkgPSAwOyBpIDwgbjsgKytpKSB7CiAgICAgICAgaWYgKGJ1ZltpXSAhPSAnYScpIAogICAgICAg ICAgcHV0Y2hhcihidWZbaV0pOwogICAgICB9CiAgICB9IHdoaWxlKG4pOwogICAgY2xvc2Uoc29j ayk7CiAgfQogIGNsb3NlKHNlcnZlcnNvY2spOwp9Cg== --20cf303dd29e349ce904bc270121 Content-Type: text/x-emacs-lisp; charset=US-ASCII; name="write-queue-issue.el" Content-Disposition: attachment; filename="write-queue-issue.el" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h09nugl21 Ozs7IC0qLSBsZXhpY2FsLWJpbmRpbmc6IHQgLSotCgooZGVmdW4gdGVzdC1tYW55LWNvbm5lY3Rp b25zICgpIAogIChsZXQqICgoY29ubmVjdGlvbiAob3Blbi1uZXR3b3JrLXN0cmVhbSAKICAgICAg ICAgICAgICAgICAgICAgICJsb2NhbGhvc3QiIG5pbCAibG9jYWxob3N0IiAxMjM0NSkpCiAgICAg ICAgIChzdHIgKGxldCAoKHZhciAiIikpIAogICAgICAgICAgICAgICAgKGRvdGltZXMgKGkgNTAw MCB2YXIpIAogICAgICAgICAgICAgICAgICAoc2V0cSB2YXIgKGNvbmNhdCAiYWFhYWFhYWFhYWFh YWFhYWFhYWFhYWFhYWEiIHZhcikpKSkpKQogICAgKGRvdGltZXMgKGkgMzAgY29ubmVjdGlvbikK ICAgICAgKHJ1bi13aXRoLWlkbGUtdGltZXIgCiAgICAgICAwLjAwMDEgbmlsIChsYW1iZGEgKCkg CiAgICAgICAgICAgICAgICAgICAgKHdpdGgtdGVtcC1idWZmZXIgIAogICAgICAgICAgICAgICAg ICAgICAgKGluc2VydCBzdHIpCiAgICAgICAgICAgICAgICAgICAgICAoaW5zZXJ0ICJcbiIpCiAg ICAgICAgICAgICAgICAgICAgICAoaW5zZXJ0IChudW1iZXItdG8tc3RyaW5nIGkpKQogICAgICAg ICAgICAgICAgICAgICAgKG1lc3NhZ2UgIlNlbmRpbmc6ICVTIiBpICkKICAgICAgICAgICAgICAg ICAgICAgIChwcm9jZXNzLXNlbmQtcmVnaW9uIGNvbm5lY3Rpb24gCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAocG9pbnQtbWluKSAKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIChwb2ludC1tYXgpKQogICAgICAgICAgICAgICAgICAg ICAgKG1lc3NhZ2UgIiVTIHNlbnQiIGkpKSkpKSkpCgooc2V0cSBvdXItdGVzdC1wcm9jZXNzCiAg ICAgIChwcm9nbiAod2hlbiAoYm91bmRwICdvdXItdGVzdC1wcm9jZXNzKSAoZGVsZXRlLXByb2Nl c3Mgb3VyLXRlc3QtcHJvY2VzcykpIAoJICAgICAodGVzdC1tYW55LWNvbm5lY3Rpb25zKSkpCg== --20cf303dd29e349ce904bc270121 Content-Type: text/x-patch; charset=US-ASCII; name="10815.patch" Content-Disposition: attachment; filename="10815.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h09nwuuo2 PT09IG1vZGlmaWVkIGZpbGUgJ3NyYy9wcm9jZXNzLmMnCioqKiBzcmMvcHJvY2Vzcy5jCTIwMTIt MDMtMjMgMTI6MjM6MTQgKzAwMDAKLS0tIHNyYy9wcm9jZXNzLmMJMjAxMi0wMy0yNiAxNToyMDoz MCArMDAwMAoqKioqKioqKioqKioqKioKKioqIDYzMSw2MzYgKioqKgotLS0gNjMxLDYzNyAtLS0t CiAgICBwLT5zdGF0dXMgPSBRcnVuOwogICAgcC0+bWFyayA9IEZtYWtlX21hcmtlciAoKTsKICAg IHAtPmtpbGxfd2l0aG91dF9xdWVyeSA9IDA7CisgICBwLT53cml0ZV9xdWV1ZSA9IFFuaWw7CiAg CiAgI2lmZGVmIEFEQVBUSVZFX1JFQURfQlVGRkVSSU5HCiAgICBwLT5hZGFwdGl2ZV9yZWFkX2J1 ZmZlcmluZyA9IDA7CioqKioqKioqKioqKioqKgoqKiogNTM2Niw1MzcxICoqKioKLS0tIDUzNjcs NTQ2MiAtLS0tCiAgICBsb25nam1wIChzZW5kX3Byb2Nlc3NfZnJhbWUsIDEpOwogIH0KICAKKyAv KiBJbiBzZW5kX3Byb2Nlc3MsIHdoZW4gYSB3cml0ZSBmYWlscyB0ZW1wb3JhcmlseSwKKyAgICB3 YWl0X3JlYWRpbmdfcHJvY2Vzc19vdXRwdXQgaXMgY2FsbGVkLgorIAorICAgIEl0IG1heSBleGVj dXRlIHVzZXIgY29kZSwgZm9yIGV4YW1wbGUgdGltZXJzLCB0aGF0IHNvbWV0aW1lcworICAgIGF0 dGVtcHQgdG8gd3JpdGUgbmV3IGRhdGEgdG8gdGhlIHNhbWUgcHJvY2Vzcy4gRGF0YSBtdXN0IGJl IGVuc3VyZWQKKyAgICB0byBiZSBzZW50IGluIHRoZSByaWdodCBvcmRlciwgYW5kIGNlcnRhaW5s eSBub3QgYmUgaW50ZXJzcGVyc2VkCisgICAgaGFsZi1jb21wbGV0ZWQgd2l0aCBvdGhlciB3cml0 ZXMuCisgICAgKFNlZSBidWcgIzEwODE1KQorIAorICAgIFRvIGFtZW5kIHRoaXMgcHJvYmxlbSB0 aGUgcHJvY2VzcyB3cml0ZV9xdWV1ZSBoYXMgYmVlbiBhZGRlZC4KKyAgICBJdCBpcyBhIGxpc3Qg d2l0aCBlYWNoIGVudHJ5IGhhdmluZyB0aGUgZm9ybToKKyAKKyAgICAoc3RyaW5nIC4gKG9mZnNl dCAuIGxlbmd0aCkpCisgCisgICAgd2hlcmUgc3RyaW5nIGlzIGEgbGlzcCBzdHJpbmcsIG9mZnNl dCBpcyB0aGUgb2Zmc2V0IGludG8gdGhlCisgICAgc3RyaW5nJ3MgYnl0ZXNlcXVlbmNlLCBmcm9t IHdoZXJlIHdlIHNob3VsZCBiZWdpbiB0byBzZW5kIGFuZAorICAgIGxlbmd0aCBpcyB0aGUgbnVt YmVyIG9mIGJ5dGVzIGxlZnQgdG8gc2VuZC4KKyAgKi8KKyAKKyAvKiBDcmVhdGUgYSBuZXcgZW50 cnkgaW4gd3JpdGVfcXVldWUsCisgCisgICAgIGlucHV0X29iaiBzaG91bGQgYmUgYSBidWZmZXIs IHN0cmluZyBvciBRdC9RbmlsCisgICAgIGJ1ZiBpcyBhIHBvaW50ZXIgdG8gdGhlIHN0cmluZyBz ZXF1ZW5jZSBvZiB0aGUgaW5wdXRfb2JqIG9yIGEgQworICAgICBzdHJpbmcgaW4gY2FzZSBvZiBR dC9RbmlsCisgKi8KKyBzdGF0aWMgdm9pZAorIHdyaXRlX3F1ZXVlX3B1c2ggKHN0cnVjdCBMaXNw X1Byb2Nlc3MgKnAsIExpc3BfT2JqZWN0IGlucHV0X29iaiwKKyAgICAgICAgICAgICAgICAgICBj b25zdCBjaGFyICpidWYsIGludCBsZW4sIGludCBmcm9udCkKKyB7CisgICBFTUFDU19JTlQgb2Zm c2V0OworICAgTGlzcF9PYmplY3QgZW50cnksIG9iajsKKyAKKyAgIGlmIChTVFJJTkdQIChpbnB1 dF9vYmopKQorICAgICB7CisgICAgICAgb2Zmc2V0ID0gYnVmIC0gU1NEQVRBIChpbnB1dF9vYmop OworICAgICAgIG9iaiA9IGlucHV0X29iajsKKyAgICAgfQorICAgZWxzZQorICAgICB7CisgICAg ICAgb2Zmc2V0ID0gMDsKKyAgICAgICBvYmogPSBtYWtlX3VuaWJ5dGVfc3RyaW5nIChidWYsIGxl bik7CisgICAgIH0KKyAKKyAgIGVudHJ5ID0gRmNvbnMgKG9iaiwgRmNvbnMgKG1ha2VfbnVtYmVy IChvZmZzZXQpLCBtYWtlX251bWJlciAobGVuKSkpOworIAorICAgaWYgKGZyb250KQorICAgICBw LT53cml0ZV9xdWV1ZSA9IEZjb25zIChlbnRyeSwgcC0+d3JpdGVfcXVldWUpOworICAgZWxzZQor ICAgICBwLT53cml0ZV9xdWV1ZSA9IG5jb25jMiAocC0+d3JpdGVfcXVldWUsIEZjb25zIChlbnRy eSwgUW5pbCkpOworIH0KKyAKKyBzdGF0aWMgdm9pZAorIHdyaXRlX3F1ZXVlX3B1c2hfZnJvbnQg KHN0cnVjdCBMaXNwX1Byb2Nlc3MgKnAsIExpc3BfT2JqZWN0IG9iaiwKKyAgICAgICAgICAgICAg ICAgICAgICAgICBjb25zdCBjaGFyICpidWYsIEVNQUNTX0lOVCBsZW4pCisgeworICAgd3JpdGVf cXVldWVfcHVzaCAocCwgb2JqLCBidWYsIGxlbiwgMSk7CisgfQorIAorIHN0YXRpYyB2b2lkCisg d3JpdGVfcXVldWVfcHVzaF9iYWNrIChzdHJ1Y3QgTGlzcF9Qcm9jZXNzICpwLCBMaXNwX09iamVj dCBvYmosCisgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCBjaGFyICpidWYsIEVNQUNTX0lO VCBsZW4pCisgeworICAgd3JpdGVfcXVldWVfcHVzaCAocCwgb2JqLCBidWYsIGxlbiwgMCk7Cisg fQorIAorIC8qIHJlbW92ZSB0aGUgZmlyc3QgZWxlbWVudCBpbiBwcm9jZXNzJyB3cml0ZV9xdWV1 ZSBhbmQKKyAgICBwdXQgaXRzIGNvbnRlbnRzIGluIG9iaiwgYnVmIGFuZCBsZW4gb3IgcmV0dXJu IC0xIGlmCisgICAgd3JpdGVfcXVldWUgaXMgZW1wdHkgKi8KKyBzdGF0aWMgaW50Cisgd3JpdGVf cXVldWVfcG9wX2Zyb250IChzdHJ1Y3QgTGlzcF9Qcm9jZXNzICpwLCBMaXNwX09iamVjdCAqb2Jq LCBjb25zdAorICAgICAgICAgICAgICAgICAgICAgICAgY2hhciAqKmJ1ZiwgRU1BQ1NfSU5UICps ZW4pIHsKKyAgIExpc3BfT2JqZWN0IGVudHJ5LCBvZmZzZXRfbGVuZ3RoOworICAgRU1BQ1NfSU5U IG9mZnNldDsKKyAKKyAgIGlmIChOSUxQIChwLT53cml0ZV9xdWV1ZSkpCisgICAgIHJldHVybiAt MTsKKyAKKyAgIGVudHJ5ID0gWENBUiAocC0+d3JpdGVfcXVldWUpOworICAgcC0+d3JpdGVfcXVl dWUgPSBYQ0RSIChwLT53cml0ZV9xdWV1ZSk7CisgCisgICAqb2JqID0gWENBUiAoZW50cnkpOwor ICAgb2Zmc2V0X2xlbmd0aCA9IFhDRFIgKGVudHJ5KTsKKyAKKyAgICpsZW4gPSBYSU5UIChYQ0RS IChvZmZzZXRfbGVuZ3RoKSk7CisgICBvZmZzZXQgPSBYSU5UIChYQ0FSIChvZmZzZXRfbGVuZ3Ro KSk7CisgICAqYnVmID0gU0RBVEEgKCpvYmopICsgb2Zmc2V0OworIAorICAgcmV0dXJuIDA7Cisg fQorIAogIC8qIFNlbmQgc29tZSBkYXRhIHRvIHByb2Nlc3MgUFJPQy4KICAgICBCVUYgaXMgdGhl IGJlZ2lubmluZyBvZiB0aGUgZGF0YTsgTEVOIGlzIHRoZSBudW1iZXIgb2YgY2hhcmFjdGVycy4K ICAgICBPQkpFQ1QgaXMgdGhlIExpc3Agb2JqZWN0IHRoYXQgdGhlIGRhdGEgY29tZXMgZnJvbS4g IElmIE9CSkVDVCBpcwoqKioqKioqKioqKioqKioKKioqIDUzNzUsNTM4MSAqKioqCiAgICAgZm9y IGVuY29kaW5nIGJlZm9yZSBpdCBpcyBzZW50LgogIAogICAgIFRoaXMgZnVuY3Rpb24gY2FuIGV2 YWx1YXRlIExpc3AgY29kZSBhbmQgY2FuIGdhcmJhZ2UgY29sbGVjdC4gICovCi0gCiAgc3RhdGlj IHZvaWQKICBzZW5kX3Byb2Nlc3MgKHZvbGF0aWxlIExpc3BfT2JqZWN0IHByb2MsIGNvbnN0IGNo YXIgKnZvbGF0aWxlIGJ1ZiwKICAJICAgICAgdm9sYXRpbGUgRU1BQ1NfSU5UIGxlbiwgdm9sYXRp bGUgTGlzcF9PYmplY3Qgb2JqZWN0KQotLS0gNTQ2Niw1NDcxIC0tLS0KKioqKioqKioqKioqKioq CioqKiA1Mzg0LDUzOTQgKioqKgogICAgc3RydWN0IExpc3BfUHJvY2VzcyAqcCA9IFhQUk9DRVNT IChwcm9jKTsKICAgIHNzaXplX3QgcnY7CiAgICBzdHJ1Y3QgY29kaW5nX3N5c3RlbSAqY29kaW5n OwotICAgc3RydWN0IGdjcHJvIGdjcHJvMTsKICAgIHZvaWQgKCp2b2xhdGlsZSBvbGRfc2lncGlw ZSkgKGludCk7CiAgCi0gICBHQ1BSTzEgKG9iamVjdCk7Ci0gCiAgICBpZiAocC0+cmF3X3N0YXR1 c19uZXcpCiAgICAgIHVwZGF0ZV9zdGF0dXMgKHApOwogICAgaWYgKCEgRVEgKHAtPnN0YXR1cywg UXJ1bikpCi0tLSA1NDc0LDU0ODEgLS0tLQoqKioqKioqKioqKioqKioKKioqIDU1MDAsNTYyNCAq KioqCiAgICBpZiAoIXNldGptcCAoc2VuZF9wcm9jZXNzX2ZyYW1lKSkKICAgICAgewogICAgICAg IHAgPSBYUFJPQ0VTUyAocHJvYyk7ICAvKiBSZXBhaXIgYW55IHNldGptcCBjbG9iYmVyaW5nLiAg Ki8KLSAKICAgICAgICBwcm9jZXNzX3NlbnRfdG8gPSBwcm9jOwotICAgICAgIHdoaWxlIChsZW4g PiAwKQotIAl7Ci0gCSAgRU1BQ1NfSU5UIHRoaXMgPSBsZW47CiAgCiEgCSAgLyogU2VuZCB0aGlz IGJhdGNoLCB1c2luZyBvbmUgb3IgbW9yZSB3cml0ZSBjYWxscy4gICovCiEgCSAgd2hpbGUgKHRo aXMgPiAwKQohIAkgICAgewohIAkgICAgICBFTUFDU19JTlQgd3JpdHRlbiA9IDA7CiEgCSAgICAg IGludCBvdXRmZCA9IHAtPm91dGZkOwohIAkgICAgICBvbGRfc2lncGlwZSA9ICh2b2lkICgqKSAo aW50KSkgc2lnbmFsIChTSUdQSVBFLCBzZW5kX3Byb2Nlc3NfdHJhcCk7CiAgI2lmZGVmIERBVEFH UkFNX1NPQ0tFVFMKISAJICAgICAgaWYgKERBVEFHUkFNX0NIQU5fUCAob3V0ZmQpKQohIAkJewoh IAkJICBydiA9IHNlbmR0byAob3V0ZmQsIGJ1ZiwgdGhpcywKISAJCQkgICAgICAgMCwgZGF0YWdy YW1fYWRkcmVzc1tvdXRmZF0uc2EsCiEgCQkJICAgICAgIGRhdGFncmFtX2FkZHJlc3Nbb3V0ZmRd Lmxlbik7CiEgCQkgIGlmICgwIDw9IHJ2KQohIAkJICAgIHdyaXR0ZW4gPSBydjsKISAJCSAgZWxz ZSBpZiAoZXJybm8gPT0gRU1TR1NJWkUpCiEgCQkgICAgewohIAkJICAgICAgc2lnbmFsIChTSUdQ SVBFLCBvbGRfc2lncGlwZSk7CiEgCQkgICAgICByZXBvcnRfZmlsZV9lcnJvciAoInNlbmRpbmcg ZGF0YWdyYW0iLAohIAkJCQkJIEZjb25zIChwcm9jLCBRbmlsKSk7CiEgCQkgICAgfQohIAkJfQoh IAkgICAgICBlbHNlCiAgI2VuZGlmCiEgCQl7CiAgI2lmZGVmIEhBVkVfR05VVExTCiEgCQkgIGlm IChwLT5nbnV0bHNfcCkKISAJCSAgICB3cml0dGVuID0gZW1hY3NfZ251dGxzX3dyaXRlIChwLCBi dWYsIHRoaXMpOwohIAkJICBlbHNlCiEgI2VuZGlmCiEgCQkgICAgd3JpdHRlbiA9IGVtYWNzX3dy aXRlIChvdXRmZCwgYnVmLCB0aGlzKTsKISAJCSAgcnYgPSAod3JpdHRlbiA/IDAgOiAtMSk7CiEg I2lmZGVmIEFEQVBUSVZFX1JFQURfQlVGRkVSSU5HCiEgCQkgIGlmIChwLT5yZWFkX291dHB1dF9k ZWxheSA+IDAKISAJCSAgICAgICYmIHAtPmFkYXB0aXZlX3JlYWRfYnVmZmVyaW5nID09IDEpCiEg CQkgICAgewohIAkJICAgICAgcC0+cmVhZF9vdXRwdXRfZGVsYXkgPSAwOwohIAkJICAgICAgcHJv Y2Vzc19vdXRwdXRfZGVsYXlfY291bnQtLTsKISAJCSAgICAgIHAtPnJlYWRfb3V0cHV0X3NraXAg PSAwOwohIAkJICAgIH0KICAjZW5kaWYKISAJCX0KISAJICAgICAgc2lnbmFsIChTSUdQSVBFLCBv bGRfc2lncGlwZSk7CiAgCiEgCSAgICAgIGlmIChydiA8IDApCiEgCQl7CiEgCQkgIGlmICgwCiAg I2lmZGVmIEVXT1VMREJMT0NLCiEgCQkgICAgICB8fCBlcnJubyA9PSBFV09VTERCTE9DSwogICNl bmRpZgogICNpZmRlZiBFQUdBSU4KISAJCSAgICAgIHx8IGVycm5vID09IEVBR0FJTgogICNlbmRp ZgohIAkJICAgICAgKQohIAkJICAgIC8qIEJ1ZmZlciBpcyBmdWxsLiAgV2FpdCwgYWNjZXB0aW5n IGlucHV0OwohIAkJICAgICAgIHRoYXQgbWF5IGFsbG93IHRoZSBwcm9ncmFtCiEgCQkgICAgICAg dG8gZmluaXNoIGRvaW5nIG91dHB1dCBhbmQgcmVhZCBtb3JlLiAgKi8KISAJCSAgICB7CiEgCQkg ICAgICBFTUFDU19JTlQgb2Zmc2V0ID0gMDsKICAKICAjaWZkZWYgQlJPS0VOX1BUWV9SRUFEX0FG VEVSX0VBR0FJTgohIAkJICAgICAgLyogQSBncm9zcyBoYWNrIHRvIHdvcmsgYXJvdW5kIGEgYnVn IGluIEZyZWVCU0QuCiEgCQkJIEluIHRoZSBmb2xsb3dpbmcgc2VxdWVuY2UsIHJlYWQoMikgcmV0 dXJucwohIAkJCSBib2d1cyBkYXRhOgohIAohIAkJCSB3cml0ZSgyKQkgMTAyMiBieXRlcwohIAkJ CSB3cml0ZSgyKSAgIDk1NCBieXRlcywgZ2V0IEVBR0FJTgohIAkJCSByZWFkKDIpICAgMTAyNCBi eXRlcyBpbiBwcm9jZXNzX3JlYWRfb3V0cHV0CiEgCQkJIHJlYWQoMikgICAgIDExIGJ5dGVzIGlu IHByb2Nlc3NfcmVhZF9vdXRwdXQKISAKISAJCQkgVGhhdCBpcywgcmVhZCgyKSByZXR1cm5zIG1v cmUgYnl0ZXMgdGhhbiBoYXZlCiEgCQkJIGV2ZXIgYmVlbiB3cml0dGVuIHN1Y2Nlc3NmdWxseS4g IFRoZSAxMDMzIGJ5dGVzCiEgCQkJIHJlYWQgYXJlIHRoZSAxMDIyIGJ5dGVzIHdyaXR0ZW4gc3Vj Y2Vzc2Z1bGx5CiEgCQkJIGFmdGVyIHByb2Nlc3NpbmcgKGZvciBleGFtcGxlIHdpdGggQ1JzIGFk ZGVkIGlmCiEgCQkJIHRoZSB0ZXJtaW5hbCBpcyBzZXQgdXAgdGhhdCB3YXkgd2hpY2ggaXQgaXMK ISAJCQkgaGVyZSkuICBUaGUgc2FtZSBieXRlcyB3aWxsIGJlIHNlZW4gYWdhaW4gaW4gYQohIAkJ CSBsYXRlciByZWFkKDIpLCB3aXRob3V0IHRoZSBDUnMuICAqLwohIAohIAkJICAgICAgaWYgKGVy cm5vID09IEVBR0FJTikKISAJCQl7CiEgCQkJICBpbnQgZmxhZ3MgPSBGV1JJVEU7CiEgCQkJICBp b2N0bCAocC0+b3V0ZmQsIFRJT0NGTFVTSCwgJmZsYWdzKTsKISAJCQl9CiAgI2VuZGlmIC8qIEJS T0tFTl9QVFlfUkVBRF9BRlRFUl9FQUdBSU4gKi8KICAKISAJCSAgICAgIC8qIFJ1bm5pbmcgZmls dGVycyBtaWdodCByZWxvY2F0ZSBidWZmZXJzIG9yIHN0cmluZ3MuCiEgCQkJIEFycmFuZ2UgdG8g cmVsb2NhdGUgQlVGLiAgKi8KISAJCSAgICAgIGlmIChCVUZGRVJQIChvYmplY3QpKQohIAkJCW9m ZnNldCA9IEJVRl9QVFJfQllURV9QT1MgKFhCVUZGRVIgKG9iamVjdCksCiEgCQkJCQkJICAgKHVu c2lnbmVkIGNoYXIgKikgYnVmKTsKISAJCSAgICAgIGVsc2UgaWYgKFNUUklOR1AgKG9iamVjdCkp CiEgCQkJb2Zmc2V0ID0gYnVmIC0gU1NEQVRBIChvYmplY3QpOwohIAogICNpZmRlZiBFTUFDU19I QVNfVVNFQ1MKISAJCSAgICAgIHdhaXRfcmVhZGluZ19wcm9jZXNzX291dHB1dCAoMCwgMjAwMDAs IDAsIDAsIFFuaWwsIE5VTEwsIDApOwogICNlbHNlCiEgCQkgICAgICB3YWl0X3JlYWRpbmdfcHJv Y2Vzc19vdXRwdXQgKDEsIDAsIDAsIDAsIFFuaWwsIE5VTEwsIDApOwogICNlbmRpZgohIAohIAkJ ICAgICAgaWYgKEJVRkZFUlAgKG9iamVjdCkpCiEgCQkJYnVmID0gKGNoYXIgKikgQlVGX0JZVEVf QUREUkVTUyAoWEJVRkZFUiAob2JqZWN0KSwKISAJCQkJCQkJIG9mZnNldCk7CiEgCQkgICAgICBl bHNlIGlmIChTVFJJTkdQIChvYmplY3QpKQohIAkJCWJ1ZiA9IG9mZnNldCArIFNTREFUQSAob2Jq ZWN0KTsKISAJCSAgICB9CiEgCQkgIGVsc2UKISAJCSAgICAvKiBUaGlzIGlzIGEgcmVhbCBlcnJv ci4gICovCiEgCQkgICAgcmVwb3J0X2ZpbGVfZXJyb3IgKCJ3cml0aW5nIHRvIHByb2Nlc3MiLCBG Y29ucyAocHJvYywgUW5pbCkpOwohIAkJfQohIAkgICAgICBidWYgKz0gd3JpdHRlbjsKISAJICAg ICAgbGVuIC09IHdyaXR0ZW47CiEgCSAgICAgIHRoaXMgLT0gd3JpdHRlbjsKISAJICAgIH0KISAJ fQogICAgICB9CiAgICBlbHNlCiAgICAgIHsKLS0tIDU1ODcsNTcyMSAtLS0tCiAgICBpZiAoIXNl dGptcCAoc2VuZF9wcm9jZXNzX2ZyYW1lKSkKICAgICAgewogICAgICAgIHAgPSBYUFJPQ0VTUyAo cHJvYyk7ICAvKiBSZXBhaXIgYW55IHNldGptcCBjbG9iYmVyaW5nLiAgKi8KICAgICAgICBwcm9j ZXNzX3NlbnRfdG8gPSBwcm9jOwogIAohICAgICAgIC8qIGlmIHRoZXJlIGlzIGFscmVhZHkgZGF0 YSBpbiB0aGUgd3JpdGVfcXVldWUsIHB1dCB0aGUgbmV3IGRhdGEKISAgICAgICAgICBpbiB0aGUg YmFjayBvZiBxdWV1ZSwgb3RoZXJ3aXNlIGp1c3QgaWdub3JlIGl0ICovCiEgICAgICAgaWYgKCFO SUxQIChwLT53cml0ZV9xdWV1ZSkpCiEgICAgICAgICB3cml0ZV9xdWV1ZV9wdXNoX2JhY2sgKHAs IG9iamVjdCwgYnVmLCBsZW4pOwohIAohICAgICAgIC8qIHVudGlsIE5JTFAgKHAtPndyaXRlX3F1 ZXVlKSAqLwohICAgICAgIGRvCiEgICAgICAgICB7CiEgICAgICAgICAgIEVNQUNTX0lOVCBjdXJf bGVuOwohICAgICAgICAgICBjb25zdCBjaGFyICpjdXJfYnVmOwohICAgICAgICAgICBMaXNwX09i amVjdCBjdXJfb2JqZWN0OwohIAohICAgICAgICAgICAvKiBpZiB3cml0ZV9xdWV1ZSBpcyBlbXB0 eSwganVzdCBpZ25vcmUgaXQgKi8KISAgICAgICAgICAgaWYgKE5JTFAgKHAtPndyaXRlX3F1ZXVl KSkKISAgICAgICAgICAgICB7CiEgICAgICAgICAgICAgICBjdXJfbGVuID0gbGVuOwohICAgICAg ICAgICAgICAgY3VyX2J1ZiA9IGJ1ZjsKISAgICAgICAgICAgICAgIGN1cl9vYmplY3QgPSBvYmpl Y3Q7CiEgICAgICAgICAgICAgfQohICAgICAgICAgICBlbHNlCiEgICAgICAgICAgICAgd3JpdGVf cXVldWVfcG9wX2Zyb250IChwLCAmY3VyX29iamVjdCwgJmN1cl9idWYsICZjdXJfbGVuKTsKISAK ISAgICAgICAgICAgd2hpbGUgKGN1cl9sZW4gPiAwKQohICAgICAgICAgICAgIHsKISAgICAgICAg ICAgICAgIC8qIFNlbmQgdGhpcyBiYXRjaCwgdXNpbmcgb25lIG9yIG1vcmUgd3JpdGUgY2FsbHMu ICAqLwohICAgICAgICAgICAgICAgRU1BQ1NfSU5UIHdyaXR0ZW4gPSAwOwohICAgICAgICAgICAg ICAgaW50IG91dGZkID0gcC0+b3V0ZmQ7CiEgICAgICAgICAgICAgICBvbGRfc2lncGlwZSA9ICh2 b2lkICgqKSAoaW50KSkgc2lnbmFsIChTSUdQSVBFLCBzZW5kX3Byb2Nlc3NfdHJhcCk7CiAgI2lm ZGVmIERBVEFHUkFNX1NPQ0tFVFMKISAgICAgICAgICAgICAgIGlmIChEQVRBR1JBTV9DSEFOX1Ag KG91dGZkKSkKISAgICAgICAgICAgICAgICAgewohICAgICAgICAgICAgICAgICAgIHJ2ID0gc2Vu ZHRvIChvdXRmZCwgY3VyX2J1ZiwgY3VyX2xlbiwKISAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgMCwgZGF0YWdyYW1fYWRkcmVzc1tvdXRmZF0uc2EsCiEgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIGRhdGFncmFtX2FkZHJlc3Nbb3V0ZmRdLmxlbik7CiEgICAgICAgICAgICAg ICAgICAgaWYgKDAgPD0gcnYpCiEgICAgICAgICAgICAgICAgICAgICB3cml0dGVuID0gcnY7CiEg ICAgICAgICAgICAgICAgICAgZWxzZSBpZiAoZXJybm8gPT0gRU1TR1NJWkUpCiEgICAgICAgICAg ICAgICAgICAgICB7CiEgICAgICAgICAgICAgICAgICAgICAgIHNpZ25hbCAoU0lHUElQRSwgb2xk X3NpZ3BpcGUpOwohICAgICAgICAgICAgICAgICAgICAgICByZXBvcnRfZmlsZV9lcnJvciAoInNl bmRpbmcgZGF0YWdyYW0iLAohICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgRmNvbnMgKHByb2MsIFFuaWwpKTsKISAgICAgICAgICAgICAgICAgICAgIH0KISAgICAgICAg ICAgICAgICAgfQohICAgICAgICAgICAgICAgZWxzZQogICNlbmRpZgohICAgICAgICAgICAgICAg ICB7CiAgI2lmZGVmIEhBVkVfR05VVExTCiEgICAgICAgICAgICAgICAgICAgaWYgKHAtPmdudXRs c19wKQohICAgICAgICAgICAgICAgICAgICAgd3JpdHRlbiA9IGVtYWNzX2dudXRsc193cml0ZSAo cCwgY3VyX2J1ZiwgY3VyX2xlbik7CiEgICAgICAgICAgICAgICAgICAgZWxzZQogICNlbmRpZgoh ICAgICAgICAgICAgICAgICAgICAgd3JpdHRlbiA9IGVtYWNzX3dyaXRlIChvdXRmZCwgY3VyX2J1 ZiwgY3VyX2xlbik7CiAgCiEgICAgICAgICAgICAgICAgICAgcnYgPSAod3JpdHRlbiA/IDAgOiAt MSk7CiEgI2lmZGVmIEFEQVBUSVZFX1JFQURfQlVGRkVSSU5HCiEgICAgICAgICAgICAgICAgICAg aWYgKHAtPnJlYWRfb3V0cHV0X2RlbGF5ID4gMAohICAgICAgICAgICAgICAgICAgICAgICAmJiBw LT5hZGFwdGl2ZV9yZWFkX2J1ZmZlcmluZyA9PSAxKQohICAgICAgICAgICAgICAgICAgICAgewoh ICAgICAgICAgICAgICAgICAgICAgICBwLT5yZWFkX291dHB1dF9kZWxheSA9IDA7CiEgICAgICAg ICAgICAgICAgICAgICAgIHByb2Nlc3Nfb3V0cHV0X2RlbGF5X2NvdW50LS07CiEgICAgICAgICAg ICAgICAgICAgICAgIHAtPnJlYWRfb3V0cHV0X3NraXAgPSAwOwohICAgICAgICAgICAgICAgICAg ICAgfQohICNlbmRpZgohICAgICAgICAgICAgICAgICB9CiEgICAgICAgICAgICAgICBzaWduYWwg KFNJR1BJUEUsIG9sZF9zaWdwaXBlKTsKISAKISAgICAgICAgICAgICAgIGlmIChydiA8IDApCiEg ICAgICAgICAgICAgICAgIHsKISAgICAgICAgICAgICAgICAgICBpZiAoMAogICNpZmRlZiBFV09V TERCTE9DSwohICAgICAgICAgICAgICAgICAgICAgICB8fCBlcnJubyA9PSBFV09VTERCTE9DSwog ICNlbmRpZgogICNpZmRlZiBFQUdBSU4KISAgICAgICAgICAgICAgICAgICAgICAgfHwgZXJybm8g PT0gRUFHQUlOCiAgI2VuZGlmCiEgICAgICAgICAgICAgICAgICAgICAgICkKISAgICAgICAgICAg ICAgICAgICAgIC8qIEJ1ZmZlciBpcyBmdWxsLiAgV2FpdCwgYWNjZXB0aW5nIGlucHV0OwohICAg ICAgICAgICAgICAgICAgICAgICAgdGhhdCBtYXkgYWxsb3cgdGhlIHByb2dyYW0KISAgICAgICAg ICAgICAgICAgICAgICAgIHRvIGZpbmlzaCBkb2luZyBvdXRwdXQgYW5kIHJlYWQgbW9yZS4gICov CiEgICAgICAgICAgICAgICAgICAgICB7CiEgICAgICAgICAgICAgICAgICAgICAgIEVNQUNTX0lO VCBvZmZzZXQgPSAwOwogIAogICNpZmRlZiBCUk9LRU5fUFRZX1JFQURfQUZURVJfRUFHQUlOCiEg ICAgICAgICAgICAgICAgICAgICAgIC8qIEEgZ3Jvc3MgaGFjayB0byB3b3JrIGFyb3VuZCBhIGJ1 ZyBpbiBGcmVlQlNELgohICAgICAgICAgICAgICAgICAgICAgICAgICBJbiB0aGUgZm9sbG93aW5n IHNlcXVlbmNlLCByZWFkKDIpIHJldHVybnMKISAgICAgICAgICAgICAgICAgICAgICAgICAgYm9n dXMgZGF0YToKISAKISAgICAgICAgICAgICAgICAgICAgICAgICAgd3JpdGUoMikJIDEwMjIgYnl0 ZXMKISAgICAgICAgICAgICAgICAgICAgICAgICAgd3JpdGUoMikgICA5NTQgYnl0ZXMsIGdldCBF QUdBSU4KISAgICAgICAgICAgICAgICAgICAgICAgICAgcmVhZCgyKSAgIDEwMjQgYnl0ZXMgaW4g cHJvY2Vzc19yZWFkX291dHB1dAohICAgICAgICAgICAgICAgICAgICAgICAgICByZWFkKDIpICAg ICAxMSBieXRlcyBpbiBwcm9jZXNzX3JlYWRfb3V0cHV0CiEgCiEgICAgICAgICAgICAgICAgICAg ICAgICAgIFRoYXQgaXMsIHJlYWQoMikgcmV0dXJucyBtb3JlIGJ5dGVzIHRoYW4gaGF2ZQohICAg ICAgICAgICAgICAgICAgICAgICAgICBldmVyIGJlZW4gd3JpdHRlbiBzdWNjZXNzZnVsbHkuICBU aGUgMTAzMyBieXRlcwohICAgICAgICAgICAgICAgICAgICAgICAgICByZWFkIGFyZSB0aGUgMTAy MiBieXRlcyB3cml0dGVuIHN1Y2Nlc3NmdWxseQohICAgICAgICAgICAgICAgICAgICAgICAgICBh ZnRlciBwcm9jZXNzaW5nIChmb3IgZXhhbXBsZSB3aXRoIENScyBhZGRlZCBpZgohICAgICAgICAg ICAgICAgICAgICAgICAgICB0aGUgdGVybWluYWwgaXMgc2V0IHVwIHRoYXQgd2F5IHdoaWNoIGl0 IGlzCiEgICAgICAgICAgICAgICAgICAgICAgICAgIGhlcmUpLiAgVGhlIHNhbWUgYnl0ZXMgd2ls bCBiZSBzZWVuIGFnYWluIGluIGEKISAgICAgICAgICAgICAgICAgICAgICAgICAgbGF0ZXIgcmVh ZCgyKSwgd2l0aG91dCB0aGUgQ1JzLiAgKi8KISAKISAgICAgICAgICAgICAgICAgICAgICAgaWYg KGVycm5vID09IEVBR0FJTikKISAgICAgICAgICAgICAgICAgICAgICAgICB7CiEgICAgICAgICAg ICAgICAgICAgICAgICAgICBpbnQgZmxhZ3MgPSBGV1JJVEU7CiEgICAgICAgICAgICAgICAgICAg ICAgICAgICBpb2N0bCAocC0+b3V0ZmQsIFRJT0NGTFVTSCwgJmZsYWdzKTsKISAgICAgICAgICAg ICAgICAgICAgICAgICB9CiAgI2VuZGlmIC8qIEJST0tFTl9QVFlfUkVBRF9BRlRFUl9FQUdBSU4g Ki8KICAKISAgICAgICAgICAgICAgICAgICAgICAgLyogUHV0IHdoYXQgd2Ugc2hvdWxkIGhhdmUg d3JpdHRlbiBpbgohICAgICAgICAgICAgICAgICAgICAgICAgICB3YWl0X3F1ZXVlICovCiEgICAg ICAgICAgICAgICAgICAgICAgIHdyaXRlX3F1ZXVlX3B1c2hfZnJvbnQgKHAsIGN1cl9vYmplY3Qs IGN1cl9idWYsIGN1cl9sZW4pOwogICNpZmRlZiBFTUFDU19IQVNfVVNFQ1MKISAgICAgICAgICAg ICAgICAgICAgICAgd2FpdF9yZWFkaW5nX3Byb2Nlc3Nfb3V0cHV0ICgwLCAyMDAwMCwgMCwgMCwg UW5pbCwgTlVMTCwgMCk7CiAgI2Vsc2UKISAgICAgICAgICAgICAgICAgICAgICAgd2FpdF9yZWFk aW5nX3Byb2Nlc3Nfb3V0cHV0ICgxLCAwLCAwLCAwLCBRbmlsLCBOVUxMLCAwKTsKICAjZW5kaWYK ISAgICAgICAgICAgICAgICAgICAgICAgLyogcmVyZWFkIHF1ZXVlLCB0byBzZWUgd2hhdCBpcyBs ZWZ0ICovCiEgICAgICAgICAgICAgICAgICAgICAgIGJyZWFrOwohICAgICAgICAgICAgICAgICAg ICAgfQohICAgICAgICAgICAgICAgICAgIGVsc2UKISAgICAgICAgICAgICAgICAgICAgIC8qIFRo aXMgaXMgYSByZWFsIGVycm9yLiAgKi8KISAgICAgICAgICAgICAgICAgICAgIHJlcG9ydF9maWxl X2Vycm9yICgid3JpdGluZyB0byBwcm9jZXNzIiwgRmNvbnMgKHByb2MsIFFuaWwpKTsKISAgICAg ICAgICAgICAgICAgfQohICAgICAgICAgICAgICAgY3VyX2J1ZiArPSB3cml0dGVuOwohICAgICAg ICAgICAgICAgY3VyX2xlbiAtPSB3cml0dGVuOwohICAgICAgICAgICAgIH0KISAgICAgICAgIH0K ISAgICAgICB3aGlsZSAoIU5JTFAgKHAtPndyaXRlX3F1ZXVlKSk7CiAgICAgIH0KICAgIGVsc2UK ICAgICAgewoqKioqKioqKioqKioqKioKKioqIDU2MzEsNTYzOCAqKioqCiAgICAgICAgZGVhY3Rp dmF0ZV9wcm9jZXNzIChwcm9jKTsKICAgICAgICBlcnJvciAoIlNJR1BJUEUgcmFpc2VkIG9uIHBy b2Nlc3MgJXM7IGNsb3NlZCBpdCIsIFNEQVRBIChwLT5uYW1lKSk7CiAgICAgIH0KLSAKLSAgIFVO R0NQUk87CiAgfQogIAogIERFRlVOICgicHJvY2Vzcy1zZW5kLXJlZ2lvbiIsIEZwcm9jZXNzX3Nl bmRfcmVnaW9uLCBTcHJvY2Vzc19zZW5kX3JlZ2lvbiwKLS0tIDU3MjgsNTczMyAtLS0tCgo9PT0g bW9kaWZpZWQgZmlsZSAnc3JjL3Byb2Nlc3MuaCcKKioqIHNyYy9wcm9jZXNzLmgJMjAxMi0wMS0x OSAwNzoyMToyNSArMDAwMAotLS0gc3JjL3Byb2Nlc3MuaAkyMDEyLTAzLTI1IDE2OjE4OjE4ICsw MDAwCioqKioqKioqKioqKioqKgoqKiogNzcsODMgKioqKgogICAgICBMaXNwX09iamVjdCBlbmNv ZGVfY29kaW5nX3N5c3RlbTsKICAgICAgLyogV29ya2luZyBidWZmZXIgZm9yIGVuY29kaW5nLiAg Ki8KICAgICAgTGlzcF9PYmplY3QgZW5jb2RpbmdfYnVmOwohIAogICNpZmRlZiBIQVZFX0dOVVRM UwogICAgICBMaXNwX09iamVjdCBnbnV0bHNfY3JlZF90eXBlOwogICNlbmRpZgotLS0gNzcsODUg LS0tLQogICAgICBMaXNwX09iamVjdCBlbmNvZGVfY29kaW5nX3N5c3RlbTsKICAgICAgLyogV29y a2luZyBidWZmZXIgZm9yIGVuY29kaW5nLiAgKi8KICAgICAgTGlzcF9PYmplY3QgZW5jb2Rpbmdf YnVmOwohICAgICAvKiBRdWV1ZSBmb3Igc3RvcmluZyB3YWl0aW5nIHdyaXRlcyAqLwohICAgICBM aXNwX09iamVjdCB3cml0ZV9xdWV1ZTsKISAgICAgCiAgI2lmZGVmIEhBVkVfR05VVExTCiAgICAg IExpc3BfT2JqZWN0IGdudXRsc19jcmVkX3R5cGU7CiAgI2VuZGlmCgo= --20cf303dd29e349ce904bc270121-- From debbugs-submit-bounces@debbugs.gnu.org Sun Jun 17 05:03:54 2012 Received: (at 10815) by debbugs.gnu.org; 17 Jun 2012 09:03:54 +0000 Received: from localhost ([127.0.0.1]:45491 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SgBOj-0007wP-6N for submit@debbugs.gnu.org; Sun, 17 Jun 2012 05:03:53 -0400 Received: from fencepost.gnu.org ([208.118.235.10]:46543) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SgBOd-0007wF-Ha for 10815@debbugs.gnu.org; Sun, 17 Jun 2012 05:03:49 -0400 Received: from cm162.gamma80.maxonline.com.sg ([202.156.80.162]:51170 helo=ulysses) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1SgBLY-0004sT-DU; Sun, 17 Jun 2012 05:00:37 -0400 From: Chong Yidong To: Troels Nielsen Subject: Re: bug#10815: #10815 counterintuitive results with process-send-string References: <4F3B837D.4050506@inria.fr> Date: Sun, 17 Jun 2012 17:00:29 +0800 In-Reply-To: (Troels Nielsen's message of "Mon, 26 Mar 2012 17:26:56 +0200") Message-ID: <87sjdu9utu.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 10815 Cc: 10815@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) Troels Nielsen writes: > I have a proposed patch, which fixes the ordering. This patch looks good, and I've have committed it to trunk after some minor edits. Thank you very much. From debbugs-submit-bounces@debbugs.gnu.org Sun Jun 17 05:04:03 2012 Received: (at control) by debbugs.gnu.org; 17 Jun 2012 09:04:03 +0000 Received: from localhost ([127.0.0.1]:45495 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SgBOt-0007x6-0q for submit@debbugs.gnu.org; Sun, 17 Jun 2012 05:04:03 -0400 Received: from fencepost.gnu.org ([208.118.235.10]:46548) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SgBOr-0007wd-3b for control@debbugs.gnu.org; Sun, 17 Jun 2012 05:04:01 -0400 Received: from cm162.gamma80.maxonline.com.sg ([202.156.80.162]:51171 helo=ulysses) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1SgBLm-0004y9-VM for control@debbugs.gnu.org; Sun, 17 Jun 2012 05:00:51 -0400 From: Chong Yidong To: control@debbugs.gnu.org Subject: close 10815 Date: Sun, 17 Jun 2012 17:00:45 +0800 Message-ID: <87txya48jm.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) close 10815 thanks From unknown Sat Aug 16 21:18:08 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sun, 15 Jul 2012 11:24:03 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator