DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:to:from:subject:date:message-id:references
	:mime-version:content-type; q=dns; s=default; b=rxbZ0RRMe2Agdyy3
	ioHdhY0NpGIykVJ/wkGLqG+V+fo+6m7+oJjrgTOa27N66PoA42uW1CCDVqHY/4Ss
	R59eIKEJ8i4DaZMlPWNkRA0bmMQdRTJW9eBbMGOJjGJjMLdItmMLr0uZx7tiwy6z
	ANTFOInUXp+YXj5AymDlMtHv/xs=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
To: cygwin@cygwin.com
From: Achim Gratz <Stromeko@nexgo.de>
Subject: Re: checking in >= 256k file fatally corrupts rcs file
Date: Wed, 09 Oct 2013 20:28:17 +0200
Lines: 20
Message-ID: <87ppreqoxq.fsf@Rainer.invalid>
References: <20131008102204.GB9241@plunk.org> <525499E5.4090608@etr-usa.com>	<52555E65.1070000@cs.utoronto.ca>
Mime-Version: 1.0
Content-Type: text/plain
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

Ryan Johnson writes:
> So in other words, a misguided performance optimization [1] that
> almost certainly has little measurable impact on performance [2] has
> introduced a silent data corruption bug (or tickled a latent one
> somewhere else). Lovely.

It is not the performance optimization that isn't working, but the code
path through plain stdio while doing a diff that was probably never
exercised (the tests all pass on Cygwin).  Try RCS_MEM_LIMIT=0 to force
stdio.  The error does not occur on Linux and it doesn't seem to be
known to the devs.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables


--
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