[latch]

Author here.

I finally got it working. I had to flush both the encrypted writer and then the stream writer. There was also some issues with reading. Streaming works, but it'll always return 0 on the first read because Writer.Fixed doesn't implement sendFile, and thus after the first call, it internally switches from streaming mode to reading mode (1) and then things magically work.

Currently trying to get compression re-enabled in my websocket library.

(1) https://github.com/ziglang/zig/blob/47a2f2ddae9cc47ff6df7a71...

[dchest]

Ha, "Don't Forget to Flush" https://www.youtube.com/watch?v=f30PceqQWko

[jenadine]

That's why I like RAII.

[AndyKelley]

It's a bug to flush (fallible operation) in a destructor (infallible operation).

[oconnor663]

I know you've thought carefully about these issues, but still it can't be that simple, can it? Closing a file or a socket is a fallible operation too.

[AndyKelley]

Wrong.

[MrResearcher]

Why is he wrong?

Here's an excerpt from the close(2) syscall description:

RETURN VALUE close() returns zero on success. On error, -1 is returned, and errno is set to indicate the error.

ERRORS EBADF fd isn't a valid open file descriptor.

       EINTR  The close() call was interrupted by a signal; see signal(7).

       EIO    An I/O error occurred.

       ENOSPC
       EDQUOT On NFS, these errors are not normally reported against the first write which exceeds the available storage space, but instead against a subsequent
              write(2), fsync(2), or close().

       See NOTES for a discussion of why close() should not be retried after an error.

It obviously can fail due to a multitude of reasons.

[bnolsen]

Hidden control flow violates the zig manifesto.

[tempodox]

Whatever happened to the principle of least surprise?

[DrewADesign]

Unsurprisingly, it’s occasionally disregarded—seemingly when you least expect it.

[selfmodruntime]

Going from the previous interface to what ever this is, is certainly something. Yeesh.