On 16 Feb 2007, at 1:06, Keith Hodges wrote:

> I don't think that it is as simple as that, have a look at  
> CrLfFileStream
> new. In 3.9 this invokes MultiByteFileStream instead. Perhaps the
> problem lies there instead.

I'm by no means an expert on MultiByteFileStreams, but I don't think  
that this makes any difference to the problem that I'm highlighting.

MultiByteFileStream has its own version of detectLineEndConvention,  
but it's clearly been copied from CrLfFileStream (and then some saves  
and restores of the converter have been added, in all (?) of the  
right places).  Consequently the role played by LineEndDefault is the  
same, and the fact that OSX systems get this set wrong on every  
startup has the same impact.   The fix that I posed should not  
adversely affect MultiByteFileStreams.

Related but tangential:

I believe that both of these detectLineEndConvention methods should  
be using  ensure: to do the resetting of the stream state, and then  
they could be refactored into one. I also agree that TextFile makes  
more sense than CrLfFileStream.  The latter is not part of the  
standard, and could be deprecated, and implemented as a TextFile.   
Allowing a CrLfFileStream to be a binary stream seems bogus, but  
maybe there is a reason.

Andrew P. Black
Department of Computer Science
Portland State University
+1 503 725 2411



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20070216/60a42e98/attachment.htm