532834 - nsIBinaryOutputStream.writeByteArray should not be faux-atomic

Status: NEW

(Core :: XPCOM, defect)

Description

[Jeff Walden [:Waldo]]

Suppose you have binary data to write to an asynchronous output stream.  It's binary, so it's technically not safe to just use nsIOutputStream.write(str, strlen).  nsIBinaryOutputStream.writeByteArray is generally the recommended alternative -- but it's an all-or-nothing method, and if not all bytes can be written none of them will be.  (Actually, I just checked the tree's implementation, it's worse than that -- an indeterminate number of bytes are written to the stream!)

There's no way to tell how many bytes can be written to an output stream except by trying.  (You'd think asyncWait would support this, but the requestedCount argument to it is only a hint, and the chief nsIAsyncOutputStream implementation in xpcom/io/nsPipe3.cpp treats it as such.  Thus, usually all you can know is that *some* data may be written, or that the stream is closed.)  If nsIOutputStream.write(str, strlen) can't handle binary data, and writeByteArray fails uncontrollably, what's the alternative for writing out large amounts of binary data?  Writing out the bytes individually?  I'm not aware of anything else.

nsIBinaryOutputStream.writeByteArray should be changed so that it returns the number of bytes written.  (Documentation should clarify the potential errors it returns as well, although this is a slightly tangential concern.)  Its behavior, even in case of error, would then be predictable, and it would be possible to use it to write data to asynchronous streams.

Alternately, since this is an ancient interface that we might not want to change in a way that could silently break stuff, I'm fine adding a new method that's actually usable, although I will mourn the loss of the intuitive name for the method.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.