On Sun, Oct 04, 2026 at 07:34:17AM +0300, Eli Zaretskii wrote: > > 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.
No, I am talking about input files. In the tests, there is a file with a CRLF because there is an explicit CR at the end of the line. tta/perl/t/input_files/only_special_spaces_node.texi Currently, the CR is removed on Windows with text I/O, while on GNU/Linux, the CR is left. This leads to a different tree (and probably different output). > 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? Because of the case above of an explicit CR in at the end of line before a LF, which is not removed in GNU/Linux. > If you are talking about producing Unix-style LF-only output files, Output is ok, my understanding is that producing native newlines is ok, which is what we do, except for Info output file that we open in binary mode, as you say. > If we read input in binary mode, then indeed we need to remove CR "by > hand". We may not need to do it in general, but we need to do it if we want to have CRLF treated the same on GNU/Linux and Windows, by removing CR in both cases. We do not necessarily need to do it for every input file, for example we may not need to do that for CSS files or htmlxref files until we add a test file with CRLF, but my feeling is that it would be more robust and consistent if we did it for every input file. -- Pat
