hSeek on text files
duncan.coutts at worc.ox.ac.uk
Fri Jul 28 06:52:10 EDT 2006
On Thu, 2006-07-27 at 15:13 +0400, Bulat Ziganshin wrote:
> Hello Simon,
> Simon, are you remember problem with using hTell+hSeek on handles open
> in text (not binary) mode on Windows? afair, you was finished with the
> decision to use NoBuffering for text files on Windows?
> but this solution is very inefficient. i now thought about dealing
> with the same problem in my lib and found that there is another
> solution - prohibit using of hTell/hSeek on files open in text mode
> (on Unix, too?). i think this is better - one should either open file
> in binary mode and use random access or open file in text mode and
> read/write it sequentially. what you think about it?
> also, i will be glad to hear comments from other haskellers
According to MS documentation:
For streams opened in text mode, fseek has limited use, because
carriage return — linefeed translations can cause fseek to
produce unexpected results.
The only fseek operations guaranteed to work on streams opened
in text mode are as follows:
* Seeking with an offset of 0 relative to any of the
* Seeking from the beginning of the file with an offset
value returned from a call to ftell
It's a good point that you might want to seek to a point previously
remembered with hTell, so we probably don't want to ban it entirely.
I could not find any documentation in the Win32 API describing the
behaviour of text files vs binary files. Is this translation behaviour
only implemented at the MS C library layer?
More information about the Libraries