hSeek on text files

Duncan Coutts 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
                origin values.
              * 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 mailing list