New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cannot read integers from stdin using scala.io.StdIn.readInt() #543
Comments
Thanks for the bug report! |
The issue is that we don't wrap stdin in https://github.com/scala-native/scala-native/blob/master/javalib/src/main/scala/java/lang/System.scala#L35, should be trivial to fix. |
Is an implementation of a CFileInputStream class sufficient to fix this ? |
@Korf74 Yes, that's exactly what needs to be done here. |
var in: InputStream = new CFileInputStream(stdio.stdin)
var out: PrintStream = new PrintStream(new CFileOutputStream(stdio.stdout))
var err: PrintStream = new PrintStream(new CFileOutputStream(stdio.stderr))
private class CFileOutputStream(stream: Ptr[stdio.FILE])
extends java.io.OutputStream {
private val buf = stdlib.malloc(1)
def write(b: Int): Unit = {
!buf = b.toUByte.toByte
stdio.fwrite(buf, 1, 1, stream)
}
}
private class CFileInputStream(stream: Ptr[stdio.FILE])
extends java.io.InputStream {
private val buf = stdlib.malloc(1)
override def read(): CInt = {
stdio.fread(buf, 1, 1, stream)
(!buf).toInt & 0xFF
}
} Calls to scala.io.StdIn.readInt() using this implementation doesn't seem to work, it seems stdin reads 32 (whitespace) in loop |
I tried with The solution I found is to use
This way we get data directly from the kernel as soon as it is available and we let There are still stuff to take care of:
|
sbt run needs to connect it's input val exitCode = Process(binary +: args).run(logger, connectInput = true).exitValue |
I use read from unistd instead of fread from stdio to prevent buffer issues. Stdio is line buffered, and we want the line to be available as soon as the user enter it, so we don't want fread to wait for the buffer to be full before returning. Resolves: #543
@MasseGuillaume reproduced this bug.
The text was updated successfully, but these errors were encountered: