Daniel Boelzle wrote: > Referring to two more samples reading out a js string out of an input > stream: > <http://developer.mozilla.org/en/docs/Reading_textual_data#Gecko_1.8_and_newer>
This works (given the loop) for file input streams and other streams that already contain all their data. I assume that's what it means to be working with, given the "fis" variable naming. For a generic input stream it would fail to read all the data. Probably worth filing a bug on this. > <http://developer.mozilla.org/en/docs/Code_snippets:File_I/O#Simple> This one is OK for now, since it's using a file input stream. > The latter uses a scriptable input stream and the scriptable input > stream implementation reads out available() bytes at most: > <http://mxr.mozilla.org/mozilla1.8/source/xpcom/io/nsScriptableInputStream.cpp#65> Right, and the only reason it's OK is that it's wrapping a file input stream. > But after all, what's the correct way of reading out an entire stream > into a js string then? For a blocking input stream, you have to read it in a loop until you get back EOF (0 bytes read). This is not so great when done on the UI thread, of course, so blocking streams are good to avoid. For a non-blocking input stream, you have to catch the WOULD_BLOCK exception read() throws and either post an event to read some more later or use the async input stream setup to be notified when more data is available. -Boris _______________________________________________ dev-tech-network mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-network
