Add stdio.write import for writing a sequence of bytes to stdout

[kg]

No description provided.

[sunfishcode]

In C/C++ code compiled to wasm, strings don't contain the "\0D", because stdout is in "text" mode, which ordinarily means that the C library translates newline into carriage-return-line-feed on Windows. However in wasm's case, the C library won't know that it's running on Windows, so it won't know that it has to do this. I think it's best if stdio.write handles this itself so that wasm programs don't have to worry about it.

[kg]

That would make it unusable for binary data.

[sunfishcode]

The alternative is to be unusable for text strings in C/C++. How about a separate function for binary data?

[kg]

write is a base primitive for writing whatever to stdout. if you want to print text, your stdlib would do any transforms like \n -> \r\n on windows.

[sunfishcode]

How should the stdlib detect that is is on Windows?

[sunfishcode]

What I'm actually concerned about here is that there's wasm code with a \r\n in it, which I find very concerning. I assumed you put it there because of Windows; if not, then can we just remove the \r?

[jfbastien]

IIUC this is meant to test that \r is unchanged. I strongly believe that fwrite shouldn't change the bits it's given, so the test should exist in some form. Are you suggesting the form be changed?

[sunfishcode]

Would you mind making a separate test for binary output then? I saw this test as the "hello world" test that would be used as an example of what wasm code looks like. I don't want to risk anyone thinking that wasm code needs a \r to print hello world.

As you say, a separate test for binary output could test \0 and other interesting characters.

[titzer]

"write" for binary data, "print" for text?

On Fri, Oct 9, 2015 at 12:34 PM, Dan Gohman notifications@github.com
wrote:

In ml-proto/test/stdio_write.wast
#121 (comment):

@@ -0,0 +1,14 @@
+(module

• (import $write "stdio" "write" (param i32 i32))

• (memory 4096 4096 (segment 0 "hello, world!\0D\0A\00"))

Would you mind making a separate test for binary output then? I saw this
test as the "hello world" test that would be used as an example of what
wasm code looks like. I don't want to risk anyone thinking that wasm code
needs a \r to print hello world.

As you say, a separate test for binary output could test \0 and other
interesting characters.

—
Reply to this email directly or view it on GitHub
https://github.com/WebAssembly/spec/pull/121/files#r41669560.

[jfbastien]

I think separate test files is fine.

[kg]

Welp. Looks like windows ocaml is doing line normalization. I probably need to find another way to write raw bytes to stdout.

======================================================================
FAIL: test/stdio_write.wast (__main__.RunTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "./runtests.py", line 37, in <lambda>
    return lambda self : self._runTestFile(*rec)
  File "./runtests.py", line 34, in _runTestFile
    self.assertEqual(expectedText, actualText)
AssertionError: '\x89PNG\r\n\x1a\n\x00' != '\x89PNG\r\r\n\x1a\r\n\x00'

[pjuftring]

I added the line

set_binary_mode_out stdout true;

And it seems to work, but I don't know if it does on linux.

[kg]

Switched to print_bytes, that might disable newline conversion. Or it might not, since Bytes is initialized from char (?????)

[rossberg]

I don't think print_bytes disables conversion (have you tried it?).

It's just like in the C or C++ stdlibs: newline conversion is a property of the stream, not the source. And stdout is a text stream. If you want to disable newline conversion on Windows, you need to go to binary mode. As @pjuftring pointed out, you can use set_binary_mode_out to change the mode after the fact. (Just make sure to switch it back before the function returns, so that you don't break other output to stdout.)

[kg]

I don't think print_bytes disables conversion (have you tried it?).

Nope, I don't have access to Windows at work :-) I'll come up with a fix on my Windows machine.
Good point about the pattern match, didn't realize you could use them on lists.

[kg]

Yeah, print_bytes doesn't disable conversion. Weird :( I'll just do set_binary_mode_out. One caveat is that you can't query the current binary mode state, so there's no way to restore it after setting it - as a result this function will trample over the output mode. I don't like that, but I can't see an alternative.

Your suggested pattern-match doesn't seem like it type-checks, at least as written. I'm not actually sure why, as it looks correct to me.

Error: This expression has type
         Eval.instance ->
         ((int32, 'a, 'b, 'c) Values.op * (int32, 'd, 'e, 'f) Values.op) list ->
         'g option
       but an expression was expected of type
         Eval.instance -> Values.value list -> 'h option
       Type (int32, 'a, 'b, 'c) Values.op * (int32, 'd, 'e, 'f) Values.op
       is not compatible with type
         Values.value = (I32.t, I64.t, F32.t, F64.t) Values.op

Should I just update the PR without using the pattern-match, or do you not want to merge without it? The pattern-match does seem like the right way to do this.

[rossberg]

Ah, sorry, I keep forgetting that OCaml separates list items by semicolons. That should fix it.

[kg]

OK, I've revised it so that it works correctly on Windows now.

Had some confusion over the fact that to disable newline normalization, you do set_binary_mode_out stdout false - the meaning of the arg is reversed.

[rossberg]

lgtm

[sunfishcode]

From a readthrough, the only use of the Eval module in this file is the Eval.memory_for_module. Can this open be removed?

[rossberg]

Closing, there doesn't seem to be a strong need