> Date: Sat, 3 Oct 2026 23:53:00 +0200 > From: Patrice Dumas <[email protected]> > > On Sat, Oct 03, 2026 at 10:38:01PM +0100, Gavin Smith wrote: > > We don't need to support input files with CRLF line endings except perhaps > > on MS-Windows-like platforms, despite the certainty expressed in the message > > you are replying to. It's a unnecessary burden that we are free to reject. > > I agree, but I do not think that it is wrong either, and to have the > same output for tests on Windows and POSIX platform it would be handy.
I don't think I understand your "but": Gavin was talking about input files, whereas you seem to be talking about output. > We could do it only if TEST is set, but always stripping a "trailing" CR > seems to me to be ok. It should not be too complicated either, we could > open in binary mode and remove a trailing CR Are you talking about input or output? On input, CR is removed automatically if you open in (the default) text mode, so why complicate things by opening input files in binary mode, in which case our application code will need to deal with removing CR? If you are talking about producing Unix-style LF-only output files, then opening the output file in binary mode is all you need to do, since there are no CRs in the text, they are added by libc if you write the output in text mode, but not in binary mode. > I think that we need to do > that anyway on Windows to handle both CRLF and LF, vurrently (with Perl) > we handle only LF on Windows, as far as I can tell (since a change I did > to set binmode and decode each line instead of setting the encoding on > the file descriptor). If we read input in binary mode, then indeed we need to remove CR "by hand".
