CrLfFileStream on MacOSX
Andrew P. Black
black at cs.pdx.edu
Fri Feb 16 20:13:12 UTC 2007
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
More information about the Squeak-dev
mailing list
|