Behaviour of QDomDocument::setContent() has nasty undocumented behaviour

Specifically, I'm talking about the QDomDocument::setContent(QIODevice*,....) functions. The implementation forcibly turns off text mode on the QIODevice*, which means if the device is already open with text translation enabled, it will be silently disabled as part of this call. There is nothing in the QDomDocument documentation to say that this occurs. There are two nasty side effects of this behaviour:

(1) The text translation behaviour of the device is left disabled upon exit, so if the device is going to be re-used, the caller would not have expected text translation to have been forcibly turned off. This is not the biggest problem though.

(2) If the data being read is textual and the platform is Windows, then the CR-LF line endings are not handled correctly for multi-line text elements. We've been chasing a problem for almost two years where our XML files were having &xd; sequences being inserted into these multi-line text nodes and we couldn't trace where they were coming from or even what conditions were causing them.

For us, (2) is the bigger problem. I've finally managed to track it down to the undocumented behaviour of QDomDocument::setContent(QIODevice*, .....). The simple but naive workaround for us is to call readAll() on the device first into a QByteArray and then pass that array to the other overload of setContent(). This ensures we get the text translation we want, but it also means that the entire XML file is going to be read in and stored first rather than letting the more efficient stream-based reading pull in the file contents.

I've listed this bug as requiring a correction to the documentation. It could be argued that the behaviour of QDomDocument::setContent(QIODevice*, .....) should be fixed, but there's a non-trivial chance that might break existing code.