Bugzilla – Bug 20674
[XT3TS] result-document-0202 and others
Last modified: 2013-01-22 09:42:24 UTC
The following tests have serializations which use '\n' as the newline character.
Elsewhere in the test suite, the newline characters used is '\r\n'.
Couldn't we simply say that assert-serialization normalizes newlines before comparison?
We do byte-by-byte comparison of the serialised result against the expected result. To get around the problem, we serialise the result both with \n and \r\n and try the comparison with each.
Is it safe to replace a 13 10 byte sequence with 10 without reference to the text encoding, or would we have to use the output encoding to decode the byte stream, do the character replacement, then re-encode to a byte stream?
I don't think we yet have mechanisms to make assertions against the binary encoding of the serialized output (though I remember thinking about how to do it). I think that the assert-serialization assertion is comparing characters, not bytes, and relies on you either (a) capturing the characters before they are encoded, or (b) decoding the binary serialization back to characters. So you should be able to normalize line endings at the character level.
What I'm currently doing works well enough, but most tests appear to have been encoded with \r\n, so I presumed it was intended to be consistent. If I remember correctly, CVS sorts this out automagically. Presumably mercurial doesn't.
I only recently switched to comparing the bytes, and can't quite remember why I made the change - I'll check my SVN logs to find out why.
BTW, there are broken links and requests for authentication for some links in the documentation at:
Would you have any objection to me making them consistent?
No, go ahead and fix them.