DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:from:to:subject:date:reply-to:message-id
	:references:in-reply-to:mime-version:content-type
	:content-transfer-encoding; q=dns; s=default; b=f3Hyrdqk3T8O2ICX
	HDFt4ao24Xp6smRT+RoupOzBpZLxFM+L7d15h02PrcnE9kHx45RIKI67BSJkMn7P
	V72g8e/KBnbxWhoo3wLhWHJcwVxyFON5BnCYWnve9MUAxYvbR0c61TshaUIdRdVZ
	Z0KdKd2TQHD2qqvw9HJ6qCkkv0Y=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
From: Bengt Larsson <lists.cygwin4@bengtl.net>
To: cygwin@cygwin.com
Subject: Re: 64-bit emacs crashes a lot
Date: Fri, 16 Aug 2013 11:07:45 +0200
Reply-To: cygwin@cygwin.com
Message-ID: <4mqr09du7v3rm4gn5oo2400grh0kovampd@4ax.com>
References: <51FB9228.2020309@cornell.edu> <51FBA100.90005@cs.utoronto.ca> <51FD5462.5020400@cs.utoronto.ca> <51FFBDFF.7040501@cornell.edu> <51FFC4F2.8080909@cs.utoronto.ca> <5203D89E.6030801@cornell.edu> <5203DCCA.1010105@cs.utoronto.ca> <5205B364.8090007@cs.utoronto.ca> <52064730.50404@cornell.edu> <"52065B3C.6060104@cs.utoronto <520CCA41.3000107"@cs.utoronto.ca> <520D089A.1020806@cornell.edu> <83ioz6op5v.fsf@gnu.org> <520D4036.8010303@cs.utoronto.ca>
In-Reply-To: <520D4036.8010303@cs.utoronto.ca>
User-Agent: ForteAgent/7.10.32.1214
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ryan Johnson wrote:
>I set a breakpoint there, since I thought it was guaranteed to lead to a 
>crash if it ever ran, but it turns out that's not true. Invoking M-x 
>compile triggers the breakpoint twice in a row with the following 
>(valid!) 5-byte UTF-8:
>
>111110XX 10XXXXXX 10XXXXXX 10XXXXXX 10XXXXXX
>11111000 10001111 10111111 10111101 10111111
>
>The value is always the same, and corresponds to the code point 
>U+3FFF7F, FWIW. The backtrace seems to involve loading a file (maybe the 
>.elc contains 'compile or 'compilation-mode?), and the breakpoint does 
>not recur in subsequent compilations, presumably because they don't 
>re-load the file. Emacs continues normally from there, because the 
>leading bits are zero and the resulting code point doesn't pass the 
>0x3FFFFF limit.

Modern Emacs uses an extended UTF-8 as internal representation.

http://www.gnu.org/software/emacs/manual/html_node/elisp/Text-Representations.html

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple