X-Recipient: archive-cygwin AT delorie DOT com
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=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; 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; s=default; bh=0jSm/RZ2XxDTsUq1Tid86C
	PsO9A=; b=V5cFxTSrY76ZgZ9ah+rROYHKfIpONPHCd/cXRtmGvTpxLnb2mhuGwD
	sp6cIFg8EnpfWp4PGTZmgDzElEskBf6eta2Yhdefmutfh9C7OOxz/OdE01mwIXUI
	iDYKoV1x892Xwdt7eSc2iZAFMnr6s9nvYLJMKqCbvRw6OHQVPwLdM=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
X-Spam-SWARE-Status: No, score=-3.4 required=5.0 tests=BAYES_00,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_YE autolearn=ham version=3.3.2
From: Bengt Larsson <lists DOT cygwin4 AT bengtl DOT net>
To: cygwin AT cygwin DOT com
Subject: Re: 64-bit emacs crashes a lot
Date: Fri, 16 Aug 2013 11:07:45 +0200
Reply-To: cygwin AT cygwin DOT com
Message-ID: <4mqr09du7v3rm4gn5oo2400grh0kovampd@4ax.com>
References: <51FB9228 DOT 2020309 AT cornell DOT edu> <51FBA100 DOT 90005 AT cs DOT utoronto DOT ca> <51FD5462 DOT 5020400 AT cs DOT utoronto DOT ca> <51FFBDFF DOT 7040501 AT cornell DOT edu> <51FFC4F2 DOT 8080909 AT cs DOT utoronto DOT ca> <5203D89E DOT 6030801 AT cornell DOT edu> <5203DCCA DOT 1010105 AT cs DOT utoronto DOT ca> <5205B364 DOT 8090007 AT cs DOT utoronto DOT ca> <52064730 DOT 50404 AT cornell DOT edu> <"52065B3C DOT 6060104 AT cs DOT utoronto <520CCA41.3000107"@cs.utoronto.ca> <520D089A DOT 1020806 AT cornell DOT edu> <83ioz6op5v DOT fsf AT gnu DOT org> <520D4036 DOT 8010303 AT cs DOT utoronto DOT 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