Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Use binary mode when writing .vsgt files
We unconditionally use binary mode when reading them as we use the header to differentiate between a .vsgt and a .vsgb, and can't read the header without opening the stream first. If the stream mode is mismatched, then this can cause problems. On Unix, there are no symptoms as the only difference is whether a trailing line feed will be inserted if the file is closed and doesn't end with one - some Unices treat all files that don't end in a line feed as binary - and `AsciiOutput::write` adds one after the closing `}` anyway. On Windows, it causes a bigger problem as automatic line ending conversion only happens in text mode - binary streams read and write carriage returns and line feeds as-is, but text streams convert a CRLF sequence to just the line feed when reading and convert a lone line feed to a CRLF sequence when writing. Because of this, when reading a multiline string in a .vsgt file, like a shader listing, on Windows, the CRLF in the file would be read into memory as-is, but if the same object was written back, then the CR would be written, and then the LF would be written as CRLF, leaving CRCRLF in the file. As well as being generally gross, most software for Windows attempts to accommodate files with weird line endings, so will interpret this as a 90s Mac line ending followed by a Windows line ending, and display it as two line breaks. The alternative would be to conditionally enable binary mode after reading the header, but that would mean the stream would need to be closed and reopened, then the header skipped, which would be a nuisance. Developers writing software for Windows are generally ready to deal with explicit carriage returns in strings, so it's fine to load them. Also, this approach is consistent with the text and glsl loaders.
- Loading branch information