Update pwrite expected behavior for files opened in append mode

[wingo]

In #95, a test was added that pwrite implements POSIX semantics (https://pubs.opengroup.org/onlinepubs/9699919799/functions/write.html). Note that Linux deviates from POSIX, ignoring the "offset" argument for append-only files, instead always writing at the end: https://linux.die.net/man/2/pwrite. Wasmtime used to paper over this Linux behavior, choosing POSIX instead, but in bytecodealliance/wasmtime#8823 decided to choose the Linux behavior over POSIX, to align with Linux native, as well as WAMR and WasmEdge: bytecodealliance/wasmtime#8817. The justification was that this part of WASI was under-specified, and I think that Linux developers expected Linux pwrite behavior. In the meantime, WasmEdge actually changed their behavior to match wasmtime's old behavior; WasmEdge/WasmEdge#3062.

The current status is that the pwrite-with-append test currently fails on wasmtime, wazero, wamr, while passing on wasmedge and pywasm-runtime.

IMO either option is fine, but it would be good if wasmedge and wasmtime people could come to agreement on this issue :)

[alexcrichton]

The "true answer" here would involve futher specifying a WASIp1 API and clarifying the interactions here, but that's more-or-less pretty unlikely to happen. I believe this isn't an issue in WASIp2 since the semantics of pwrite happen entirely in wasi-libc rather than as part of the component model layer itself. Given that it might be reasonable to just remove the test for now or allow both behaviors as I don't think there's going to be a ruling about which behavior is more correct than others.

[pchickey]

My opinion is the goal of this test suite is to clarify the behaviors of wasip1 which aren't in the text of the spec itself, and hashing out those differences here rather than in the spec is fine. But also I have no real opinion on what behavior should be for this particular case, except that wasi implementations should make it behave that way on all host operating systems, see WasmEdge/WasmEdge#3062 (comment).

I'm also fine with letting the test suite accept any behavior for p1, because there are enough shipped implementations and programs of p1 that have just locked in whatever behavior here, so maybe we shouldn't spend much effort on this, especially given that p2 doesn't have this issue by construction.

@hydai since WasmEdge made a change to behavior here most recently, do you have any strong feelings on this issue?

[hydai]

IIRC, the reason we chose to change the behavior is that someone told us it was not the same as wasmtime (https://github.com/WasmEdge/WasmEdge/pull/3375/files, Apr 29, 2024), and we think it's fine to present the same behavior since WASIp1 doesn't have a specific definition. So, we made the change. However, we didn't notice that wasmtime also changed around the same time (bytecodealliance/wasmtime#8823, Jun 18, 2024).

Either option is fine with us because this is not clearly defined in WASIp1, and we are shifting our focus to WASIp2 ;-)

[pchickey]

Oh, thanks, I misread the dates and didn't realize Wasmtime was actually the one to shift right after yall... thats unfortunate!

If WasmEdge is willing to change and nobody else has a strong opinion, then lets have the test suite accept the behavior Wasmtime, WAMR, and Wazero use by "majority rules". Since that would require pywasm to change, I'll cc @mohanson.

[mohanson]

Glad to see a consensus on this issue.

I encountered this issue before, and due to the introduction of this test case #95, I chose to change the pywasm implementation by: libraries/pywasm@0275285

I will update pywasm according to the majority rules.

[wingo]

Merged #125, which allows either way. If a consensus emerges, we can change the tests :)

[wingo]

Going to leave open for a few days for comments.