From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: storm@cua.dk (Kim F. Storm) Newsgroups: gmane.emacs.pretest.bugs,gmane.emacs.devel Subject: Re: Coding system conversion error Date: Sat, 12 Feb 2005 15:34:52 +0100 Message-ID: References: <20050205170221.ZTBD24781.mxfep02.bredband.com@coolsville.localdomain> <738f9db09f1986269b8f5719d45d2dd5@swipnet.se> <4207DAF0.6000204@swipnet.se> <4209342E.5010701@swipnet.se> <165be0ad579be34852d18cc600114175@swipnet.se> <420BD292.6040607@swipnet.se> <200502120157.KAA24490@etlken.m17n.org> <30e47fd1ee5ebcc03c15fe8c905bc525@swipnet.se> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1108219311 12140 80.91.229.2 (12 Feb 2005 14:41:51 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 12 Feb 2005 14:41:51 +0000 (UTC) Cc: emacs-pretest-bug@gnu.org, emacs-devel@gnu.org, Kenichi Handa Original-X-From: emacs-pretest-bug-bounces+gebp-emacs-pretest-bug=gmane.org@gnu.org Sat Feb 12 15:41:48 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1CzySJ-00037P-EY for gebp-emacs-pretest-bug@gmane.org; Sat, 12 Feb 2005 15:41:07 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1CzyhS-0002BK-8j for gebp-emacs-pretest-bug@gmane.org; Sat, 12 Feb 2005 09:56:46 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1CzyhN-00029x-Sx for emacs-pretest-bug@gnu.org; Sat, 12 Feb 2005 09:56:42 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Czyg2-00022h-RJ for emacs-pretest-bug@gnu.org; Sat, 12 Feb 2005 09:55:23 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Czyfo-0001wt-Mc; Sat, 12 Feb 2005 09:55:04 -0500 Original-Received: from [195.41.46.235] (helo=pfepa.post.tele.dk) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CzyMA-0001n7-4l; Sat, 12 Feb 2005 09:34:46 -0500 Original-Received: from kfs-l.imdomain.dk.cua.dk (0x503e2644.bynxx3.adsl-dhcp.tele.dk [80.62.38.68]) by pfepa.post.tele.dk (Postfix) with SMTP id 1006647FEBC; Sat, 12 Feb 2005 15:34:44 +0100 (CET) Original-To: "Jan D." In-Reply-To: <30e47fd1ee5ebcc03c15fe8c905bc525@swipnet.se> (Jan D.'s message of "Sat, 12 Feb 2005 08:36:27 +0100") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) X-BeenThere: emacs-pretest-bug@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: emacs-pretest-bug.gnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-pretest-bug-bounces+gebp-emacs-pretest-bug=gmane.org@gnu.org Errors-To: emacs-pretest-bug-bounces+gebp-emacs-pretest-bug=gmane.org@gnu.org X-MailScanner-To: gebp-emacs-pretest-bug@gmane.org Xref: main.gmane.org gmane.emacs.pretest.bugs:5838 gmane.emacs.devel:33295 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:33295 "Jan D." writes: >> At first, I think xassert in lisp_data_to_selection_data >> (xselect.c) is wrong. Here, obj is generated by a Lisp code >> that may generate a multibyte string by error (as in the >> current case). But, in general, an error in Lisp code >> should not lead to abort. So, I propose this change. I >> choose string_make_unibyte instead of string_as_unibyte to >> avoid exporting Emacs' internal leading bytes. >> >> *** xselect.c 12 Feb 2005 09:54:46 +0900 1.148 >> --- xselect.c 12 Feb 2005 10:39:47 +0900 >> *************** >> *** 1908,1914 **** >> } >> else if (STRINGP (obj)) >> { >> ! xassert (! STRING_MULTIBYTE (obj)); >> if (NILP (type)) >> type = QSTRING; >> *format_ret = 8; >> --- 1908,1915 ---- >> } >> else if (STRINGP (obj)) >> { >> ! if (STRING_MULTIBYTE (obj)) >> ! obj = string_make_unibyte (obj); >> if (NILP (type)) >> type = QSTRING; >> *format_ret = 8; > > If the multibyte string is generated by an error and this is one of > the places where we can detect the error, should we not keep the > xassert? I agree, but since the source of the error is in Lisp code, it would be more helpful to signal an error rather than abort. -- Kim F. Storm http://www.cua.dk