IO problems?
Stephen Weeks
MLton@research.nj.nec.com
Thu, 1 Jun 2000 14:41:05 -0700 (PDT)
> I seem to have problems reading a file with
> BinIO in MLTon (at least under Win32):
>
> When I open a file with:
>
> val inStr = BinIO.openIn "somefile"
>
> And then call:
>
> val vec = BinIO.input inStr
>
> I get a vector of 222 bytes - this
> is OK... but if I call input again
> on the same file a get a vector of 0
> bytes - which should be like end of file.
> But the file is several kilobytes long.
>
> If I use this instead
>
> val vec = BinIO.inputN (inStr, 222)
>
> I get the same behaviour.
>
> If I use
>
> val vec = BinIO.inputN (inStr, 200)
>
> and call this 3 times I get:
> 200 bytes, 22 bytes and then 0 bytes.
>
> Have you experienced this before or
> do you know what it might be?
No, I haven't seen this before. I looked at the changelog and the
latest internal version of the TextIO module and I don't see any
bugfixes along these lines.
> It seems like some internal buffer
> which is not getting updated.
Possibly. The code that does the internal buffer update is in
basis-library/io/text-io.sml, in the updateIn function.
fun updateIn(In{fd, closed, eof, first, last, buf, ...}): unit =
if !closed
then raise IO.Io{name = "<unimplemented>",
function = "<unknown>",
cause = IO.ClosedStream}
else if !eof
then ()
else
if !first = !last
then (* need to read *)
let
val bytesRead =
PIO.readArr(fd, {buf = buf, i = 0, sz = NONE})
in if bytesRead = 0
then eof := true
else (first := 0; last := bytesRead)
end
else ()
> I know that I was the one to both port
> to Win32 and to implement BinIO - but
> I'm still not sure if the problem has
> anything to do with what I did :)
I doubt you introduced the problem, but I don't see a problem in the
code either. My best guess is that the underlying read system call is
behaving strangely on Windows. I can't really find the problem
because I don't have your setup. I can try to help you find it. My
first attempt would be to put some debugging information in the TextIO
(or BinIO) implementation. You can use the underlying C fprintf via
the FFI mechanism. Put in debugging statements whenever any of the
TextIO.input functions is called, and within updateIn so we can see
what read is returning. We'll go from there.
> And running on windows shouldn't
> be much different. I haven't tried
> under Linux, because MLTon does not
> work for native compilation any more
> on my Linux system after I upgraded to
> libc6.1 (glibc2.1 or whatever).
> Not even after recompiling MLTon.
> This is another problem that I'm
> currently having with MLTon by the
> way. I can compile just fine, but the
> resulting executables just segfaults.
I don't have a Linux system around with libc6.1. Perhaps Henry or
Suresh has one handy that they could try mlton-1999-7-12 on. Guys?