Dup of #22746?

Nope, not an exact duplicate - can reproduce on go version devel +4435fcfd6c Thu Nov 30 14:39:19 2017 +0000 linux/amd64. But note that the program above is missing a check for the error - this is the program that reproduces the output:

https://play.golang.org/p/U75TI4ouaG

$ go run f.go
2017/11/30 16:11:03 parse error on line 1, column 2: extraneous or missing " in quoted-field
exit status 1

And, as expected, on 1.9.2:

$ go1 run f.go
2017/11/30 15:54:46 things worked as I expected!

It's not obvious that this is valid since endline terminators should be "\r\n" or "\n". However, this string abruptly ends on "\r". However, it shouldn't be hard preserving the old behavior.

I naively agree with @dsnet, but I don't know the CSV landscape enough to know what's commonly produced or accepted.

Essentially, it comes down to the old behavior being equivalent to:

line = strings.TrimSuffix(strings.TrimSuffix(line, "\n"), "\r")

While the new behavior is equivalent to:

if strings.HasSuffix(line, "\r\n") {
    line = strings.TrimSuffix(line, "\r\n")
} else {
    line = strings.TrimSuffix(line, "\n")
}

The old behavior is simpler, but the new behavior is a more correct interpretation of "\r\n" and "\n" as valid newline separators. Note also that we don't treat bare "\r" as newline separators, so it doesn't make sense to me why we should allow it as the trailing marker at EOF.

Furthermore, note that the RFC actually says that newline separators should be CRLF, so the fact that we allow bare LF is technically non-compliant.

Marking this as "Needs Decision". I'm slightly in favor of saying the new behavior is correct.

FWIW I don't have a particular problem with the new behaviour. The reason I reported it was to be sure it wasn't changed by mistake and I didn't know if it was correct.

Whatever is decided, would an additional unit test be welcome to cover it?

Interestingly, I actually added a test when this behavior changed:
89ccfe4#diff-2890b6f0873dbda3ec47edcbc69f6f2aR295

We should probably restore the old behavior: a \r before EOF gets cut just like a \r before \n. I think it is debatable whether the old behavior or current behavior is more "correct", and therefore we should err on the side of preserving the behavior from the previous release.

@dsnet, interested in working on a fix?

Change https://golang.org/cl/81577 mentions this issue: encoding/csv: fold carriage return into line feeds