sorry about that -- it is my mistake. Here's my best explanation of what
In my defense, my mistake was not knowing that emacs apparently
modifies a text file when it edits it. The given text
file contained both \n-only and \r\n line separator sequences. While
in, emacs converted all the \n to \r\n, so that even though I was
used the hexadecimal mode of emacs to view the file, all I saw was the \r\n
*after* emacs had done the conversion. So with emacs' hexl-mode,
it appeared that the file did *not* have any \n-only sequences. There
is a way to turn of this helpful behavior of emacs, which I don't know.
It was a bit of a problem because when I used emacs to save subsets of the
file, the errors seen by sbcl went away, leading me to think that it is a
effect that only happens on big files. The problem was that emacs was
fixing the \n to \r\n as I saved the subsets.
I have since verified, with perl, bvi, and hexer, that the original file
fact have some \n-only separators (and these are precisely the ones that
was behaving differently on). It would also explain why cmucl also had
the same weird behavior.
I believe there's nothing wrong with sbcl in this regard; nothing to fix :-)
again, my apologies.