hPutStr uses different line endings in different buffering modes on Windows

I haven't tried to repro this so sorry if this is a false positive.

I was looking at what line endings langs/compilers/runtimes print on Win and Linux/osx.

It looks like GHC, on Windows, prints \n in NoBuffering mode, but \r\n in LineBuffering mode.

Code for NoBuffering: https://github.com/ghc/ghc/blob/b57200de601e4ef6827727176611d7192016b8b2/libraries/ghc-internal/src/GHC/IO/Handle/Text.hs#L654

This prints \n regardless of what the handle's line ending is.

When buffered, the same function calls writeBlocks with the handle's line ending passed, which I think will print \r\n in: https://github.com/ghc/ghc/blob/b57200de601e4ef6827727176611d7192016b8b2/libraries/ghc-internal/src/GHC/IO/Handle/Text.hs#L689

Secondly, the expected behavior of what hPutStrLn, readLn and similar "print/write or read with newline" should print or expect for the line endings should be documented. I checked putStrLn, hPutStrLn, and readLn. I don't know what other similar functions exist.

As an example, this is the Rust docs specifying expected line endings in read and write functions:

• https://doc.rust-lang.org/std/io/trait.BufRead.html#method.read_line (expects \n regardless of the platform, \r will be part of the yielded lines)
• https://doc.rust-lang.org/std/macro.writeln.html (writes \n regardless of the platform)