1783709 - The nsIUnicharOutputStream API has no support for handling short writes

Status: RESOLVED WONTFIX

(Core :: XPCOM, defect)

Description

[Nika Layzell [:nika] (ni? for response)]

This is a similar problem to bug 1170668, but for the output stream type rather than the input stream type. Callers of nsIUnicharOutputStream are not told how many bytes were successfully written when it is used (the methods return boolean), and the underlying implementation doesn't attempt to re-try partial writes, meaning that there is way to recover from short writes when using nsIUnicharOutputStream.

This could happen in many cases such as when the underlying stream is a file, and the underlying system call only consumes part of the provided input buffer.

These input streams should probably either have their API changed to report the number of bytes successfully written (requiring callers to do re-tries) or to re-try internally under the hood.

Given the current JS consumers of the API I found in-tree appear to generally ignore the return value from writeString, the "re-try under the hood" approach may be more reliable due to not requiring loops at every caller of the API, making using it less error-prone.

Comment 1

[Nika Layzell [:nika] (ni? for response)]

Given that almost all uses of this are for use with nsFIleOutputStream which shouldn't short-write because PR_Write has built-in protections against that (see https://searchfox.org/mozilla-central/rev/4f2984be127d2e7c788cf1848d63dca63022beec/nsprpub/pr/src/pthreads/ptio.c#892-898), this is probably non-essential, and we may be able to get away with doing nothing here, or returning the number of utf-16 code units written and expecting callers using non-file streams to handle it as-needed.