The Interop.WriteLine output on Windows OpenCL was always less than desirable - showing "\r\n" in the output instead of a newline. We suspected this was an OpenCL driver issue.
This PR fixes the output by addressing two issues.
The first issue is that escaping \ was the last step, which incorrectly double-escaped all previous escapes.
The second issue is that \r\n is a Windows convention, but C-printf normally uses just \n. The underlying C-printf implementation then converts \n to \r\n on Windows devices. To handle this, we use Environment.NewLine to deal with whether we are running on Windows or Unix. Without converting \r\n as a single translation, my OpenCL implementation would translate \r to "r", and then \n to a newline.
The
Interop.WriteLineoutput on Windows OpenCL was always less than desirable - showing "\r\n" in the output instead of a newline. We suspected this was an OpenCL driver issue.This PR fixes the output by addressing two issues.
The first issue is that escaping
\was the last step, which incorrectly double-escaped all previous escapes.The second issue is that
\r\nis a Windows convention, but C-printf normally uses just\n. The underlying C-printf implementation then converts\nto\r\non Windows devices. To handle this, we useEnvironment.NewLineto deal with whether we are running on Windows or Unix. Without converting\r\nas a single translation, my OpenCL implementation would translate\rto "r", and then\nto a newline.The fixed output now looks correct: