X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-2.7 required=5.0	tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST
X-Spam-Check-By: sourceware.org
MIME-Version: 1.0
In-Reply-To: <BANLkTinyfwi1Fkah76BAYX9YJwucsbUdLw@mail.gmail.com>
References: <4DD36619 DOT 1010401 AT hima DOT com>	<BANLkTino_ZBUjCzbrmLezRJqjz2Y+04DCQ AT mail DOT gmail DOT com>	<BANLkTinyfwi1Fkah76BAYX9YJwucsbUdLw AT mail DOT gmail DOT com>
Date: Tue, 7 Jun 2011 10:54:58 -0500
Message-ID: <BANLkTikD_CYSqSg3FagsefDmx-rhaHGH1Q@mail.gmail.com>
Subject: Re: 1.7.9: Problem with line endings of Perl output redirected to a file with textmode mounting
From: "Craig A. Berry" <craig DOT a DOT berry AT gmail DOT com>
To: Reini Urban <rurban AT x-ray DOT at>
Cc: cygwin AT cygwin DOT com, pp <perl5-porters AT perl DOT org>
Content-Type: text/plain; charset=ISO-8859-1
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT 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

On Tue, Jun 7, 2011 at 8:40 AM, Reini Urban <rurban AT x-ray DOT at> wrote:
> 2011/5/24 Reini Urban:
>> 2011/5/18 Sven Severus:

>>> Ups! The original <cr> <lf> sequence starting at offset 4095 (0xfff)
>>> became a three character sequence <cr> <cr> <lf>! The <cr> is duplicated!
>>>
>>> In other files created by Perl with output redirection I observed this
>>> behaviour with every <cr> <lf> line ending, that is split by a 4096 byte
>>> boundary (even multiple times in one output file). Line endings not
>>> split by a 4096 byte boundary do not show this behaviour.

>>> I this a bug of the output buffering mechanism of Cygwin Perl?
>>> Or do I anything wrong?
>>> Any answer is highly appreciated. Thanks in advance.
>>
>> Yes, this looks like a PerlIO buffering bug for MSWin32 and cygwin.
>> The last char of the buffer is not stored when checking the first char
>> of the new buffer.
>> I think first we have to provide a sample test case to perl core.
>
> I could not reproduce it in perl core with the PerlIO :crlf layer, see
> attached test.
> I'm investigating cygwin buffer edge-case handling now.

I don't see Perl versions mentioned here, but note that the default
PerlIO buffer size was 4096 for many years until 5.14.0, at which
point it became the larger of 8192 and BUFSIZ.  So if you're testing
with blead, you may see the behavior at a different offset than 4096,
assuming this involves something getting tangled up between PerlIO
buffer flushing and the Windows-specific crlf layer managing its line
endings.

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