From: Omar Polo <op@omarpolo.com>
Subject: Re: got patch: handle "\ No newline at end of file"
To: Stefan Sperling <stsp@stsp.name>
Cc: gameoftrees@openbsd.org
Date: Sat, 19 Mar 2022 19:33:54 +0100

Stefan Sperling <stsp@stsp.name> wrote:
> Should we handle CRLF newlines? It seems your code would split such
> lines at LF, leaving a trailing CR in place.
> Or do we only assume unix semantics and support just \n, not \r\n?

I completely forgot about this issue.  at least at the moment I'm
assuming unix semantics and only LF as line terminator.

> Does Larry's patch even handle CRLF?

diff(1) seems to transform CRLF into LF, and patch(1) doesn't seem to
handle CRLF.  I tried:

	% printf 'hello\r\n' > hello
	% patch << EOF
	--- hello
	+++ hello
	@@ -1 +1,2 @@
	 hello
	+world
	EOF
	...
	Hunk #1 succeeded at 1 with fuzz 1.
	done
	% hexdump -C hello
	00000000  68 65 6c 6c 6f 0d 0a 77  6f 72 6c 64 0a   |hello..world.|
	0000000d

and it "worked" only because of "with fuzz 1" (i.e. it failed to match
the line with "hello" due to the CR but went ahead anyway.)

> There is also an older(?) convention on Mac that uses just \r for newlines.

tried just for fun and, as expected, nope.  diff(1) has issue handling
those too.

> FWIW, svn patch supports all of these, but only because every part
> of SVN has to support them. We don't necessarily have to do the same,
> but we should make a decision and document it.

I'd say to just assume \n as newline as patch(1) and diff(1) do.  But if
we want to handle CRLF too at some point it shouldn't be incredibly
hard.  \r alone instead don't seems to be worth imho.