From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: bug#7517: 24.0.50; repeated crash under Mac OS X Date: Fri, 31 Dec 2010 18:07:22 -0500 Message-ID: References: <87tyic1uzh.fsf@stupidchicken.com> <87vd2dyzfj.fsf@stupidchicken.com> <4D1B22A1.6080202@swipnet.se> <4D1B27AF.7010701@swipnet.se> <4D1C6E7D.2040300@swipnet.se> <4D1D0172.8080404@swipnet.se> <4D1DB555.5080002@swipnet.se> <4D1DBD4A.6010303@swipnet.se> <83d3oiaysj.fsf@gnu.org> <4D1DD655.1040809@swipnet.se> <83aajmaxme.fsf@gnu.org> <4D1E5987.2000502@swipnet.se> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1293836859 8153 80.91.229.12 (31 Dec 2010 23:07:39 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 31 Dec 2010 23:07:39 +0000 (UTC) Cc: "Uday S. Reddy" , emacs user , cyd@stupidchicken.com, emacs-devel@gnu.org, 7517@debbugs.gnu.org, Eli Zaretskii To: Jan =?iso-8859-1?Q?Dj=E4rv?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 01 00:07:34 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PYo4K-0005kp-2v for ged-emacs-devel@m.gmane.org; Sat, 01 Jan 2011 00:07:32 +0100 Original-Received: from localhost ([127.0.0.1]:36200 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PYo4J-0004sb-7F for ged-emacs-devel@m.gmane.org; Fri, 31 Dec 2010 18:07:31 -0500 Original-Received: from [140.186.70.92] (port=37158 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PYo4E-0004sW-LL for emacs-devel@gnu.org; Fri, 31 Dec 2010 18:07:27 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PYo4D-000284-Jt for emacs-devel@gnu.org; Fri, 31 Dec 2010 18:07:26 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:61960 helo=ironport2-out.pppoe.ca) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PYo4C-00027h-B5; Fri, 31 Dec 2010 18:07:24 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAC/wHU1Ld/TY/2dsb2JhbACkPXS+E4VKBIRljhs X-IronPort-AV: E=Sophos;i="4.60,256,1291611600"; d="scan'208";a="86855276" Original-Received: from 75-119-244-216.dsl.teksavvy.com (HELO pastel.home) ([75.119.244.216]) by ironport2-out.pppoe.ca with ESMTP/TLS/ADH-AES256-SHA; 31 Dec 2010 18:07:23 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id D6C5E58A74; Fri, 31 Dec 2010 18:07:22 -0500 (EST) In-Reply-To: <4D1E5987.2000502@swipnet.se> ("Jan =?iso-8859-1?Q?Dj=E4rv=22?= =?iso-8859-1?Q?'s?= message of "Fri, 31 Dec 2010 23:30:31 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:134093 Archived-At: >>> Emacs should never use unibyte strings for buffer names. >> I don't think we make any effort to prevent this from happening. >> And I'm not completely sure that it would be worth the trouble either: >> I suspect that wherever a unibyte buffer-name would cause problem >> (mode-line, window title, younameit), some other unibyte string could >> appear from elsewhere just as well, so enforcing multibyte buffer-names >> wouldn't close the vulnerabilities. > If we don't at least ENCODE_UTF_8 should do the right thing. Is the coding > for these kind of strings known? If not and we don't enforce encoding in > basic interfaces, we must deal with all existing encodings? I'd tend to agree. ENCODE_UTF_8 is used for things where we *really* want the output to be proper utf-8, so any char outside of utf-8 (e.g. an eight-bit char) should result in something else than a raw byte in the output. This is contrary to what we do for utf-8 files, where we output eight-bit chars as raw bytes (because any sequence of bytes that's not valid utf-8 in the input leads to such eight-bit chars in the buffer, so outputting them as raw bytes is used to preserve the file unchanged when saved). Stefan