[RFC] libstdc++/20806 or read syscall changing \r\n to \n on mingw

Nathan Myers ncm-nospam@cantrip.org
Thu Apr 7 14:23:00 GMT 2005


On Thu, Apr 07, 2005 at 03:48:50PM +0200, Paolo Carlini wrote:
> I'm trying to help the mingw32 people with this issue, which affects
> istream::read. The problem is that the underlying filebuf::xsgetn
> implements (since 3.4) the optimization of issuing a single
> _M_file.xsgetn, which copies directly into the destination buffer: on
> mingw32, the underlying read syscall, for files opened in char mode (not
> binary mode), strips \r from sequences \r\n and therefore, short reads
> are produced when, in fact, eof is *not* reached.
> 
> A first possibility is [special-case text-mode reads]
> Another one, special casing mingw32.
> 
> A third one, taking somewhow into account in _M_file.xsgetn the
> possibility of short reads, but this is not at all trivial, because with
> pipes/fifos, after a first short read, the next ones *block*, and we
> obtain regressions for time-out in the testsuite if we try just using a
> loop :(

Special-casing win32 (of whatever stripe), and any other environment in
which text mode mangles the stream, seems fundamentally necessary.  It 
raises the question, though, of what to do in the special case.  Turning 
off the optimization for the case of win32 text-mode seems safe enough 
for 4.0.  People who care about speed, there, do binary reads.

There might be something that can be done with FIONREAD.  Maybe the 
people who care most will do the work, once the bottleneck is safely 
sequestered in an #ifdef.  

Nathan Myers
ncm@cantrip.org
ncm@codesourcery.com



More information about the Libstdc++ mailing list