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: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wceappdev5/... 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? Duncan