Re: 1.7.9: Problem with line endings of Perl output redirected to a file with textmode mounting

["Craig A. Berry" <craig dot a dot berry at gmail dot com>]

On Tue, Jun 7, 2011 at 8:40 AM, Reini Urban <rurban@x-ray.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