Binary IO

[Simon Marlow]

On 22 April 2005 11:35, Benjamin Franksen wrote:

> On Friday 22 April 2005 10:38, Simon Marlow wrote:
>> Lifting this constraint in GHC is a bit tricky because we currenly
>> use the OS's text<->binary translation to do I/O (doesn't matter on
>> Unix, right now).
> 
> So what? If the handle is in text mode, you won't get the exact bytes
> as they are in the file, when calling hGetWord8 (at least on some
> systems). But that is exactly what I would expect if the handle is in
> text mode. If I need the exact binary representation of a text file, I
> have to use binary, of course.

So if you open a file in text mode and read it with hGetWord8, what
bytes do you expect to get, exactly?  Perhaps each byte of the UCS-4
representation?  Big endian or little endian order?  

You could specify some meaning, but I don't think it would be a useful
interface.  And if you can't specify it precisely, it shouldn't be
there.

>> I presume that hPutWord8 (fromIntegral (ord '\n')) should not flush a
>> line-buffered Handle,
> 
> I can't see a reason not to flush it. Could you explain why you think
> it should not? What have terminal settings to do with file handle
> modes?? 

Well, I have the notion that EOL is a text concept, so doesn't belong in
binary I/O.  On the other hand, it's easy enough to specify that writing
the byte 0xa to a line-buffered binary handle has the effect of flushing
it, just as we say that writing the character '\n' to a line-buffered
text handle triggers a flush.  So I'm happy to leave things as they are.

Cheers,
	Simon