Line-ending related FORMAT directive bug on Windows

[Tim Bradshaw]

This problem is slightly apocryphal as I don't have a Windows machine, so I am reporting it second-hand. It originates with a Stack Overflow question: https://stackoverflow.com/questions/65104710/running-jwacs-lisp-program-under-64-bit-windows (and in particular you need to look at some of the comments to see the problem).

When compiling jwacs (https://github.com/chumsley/jwacs), checked out with git on a Windows machine, SBCL falls over when trying to process a format directive. That directive is 'tilde newline' (CLHS 22.3.9.3) which allows nicely-formatted continuation lines in format control strings.

The problem, I think, is that what SBCL is seeing is a tilde followed by a return character, and it is (correctly) barfing because of this. And it's seeing that because of course the files have CR/LF line-endings on Windows defaultly.

If I am correct in my understanding of the problem it should be easy to reproduce: simply create a (Windows / CR/LF) encoded file containing

(format t "~&x~
           y~%")

and try to load it on Windows (such a file is attached to this report, although I may have botched the format so it's actually OK).

It's fairly clear from the spec (13.1.8) that CR/LF should be translated to /from newline if/when CR/LF is the natural encoding, which it probably is for Windows. It looks as if that's happening everywhere *except* when reading strings.

It is probably arguable that it should not happen when reading strings, but it's clearly more useful that it should I think: certainly it would avoid problems like that described here.

The particular problem here can be worked around by simply telling git to check the files out with their native (linefeed) encoding, but the underlying problem is still there.

Note I realise that line-end encodings are a big can of worms: I just wanted there to be a record of this problem.

[Tim Bradshaw (tfeb)]

While 720517 looks like it's the same thing, the actual description of that bug (which involves checking what character the system prints) is nothing like this one.

I don't mind either way, but that's why I raised this one as well.

[Stas Boukarev (stassats)]

But the issue is the same.