Re: Why does Lua not want to write 13 to binary files on Windows?

[Francisco Olarte <folarte@...>]

Mouse:

On Wed, 15 Feb 2023 at 19:34, Mouse <mouse@rodents-montreal.org> wrote:
> No, but it may well apply to other tools.  In particular, it would not
> surprise me if the reason the hex dumper mentioned upthread didn't
> display it correctly had something to do with the Windows tendency to
> represent line breaks as CRLF instead of NL.

Windows defines the end-of-line as \015\012, internet newlines,
inherited from DOS, CP/M and ultimately paper printers, it does not
cause problems, as old macintoshes used \015 ( and some of them
translated \n to \015 and \r to \012 ). The problem is not the OS, it
is the C runtimes used there.

> (A hex dumper _should_ be
> using binary mode, or the analog for whatever language it's written in.

I'll even say a Windows hex dumper should be using native windows APIs
to read data, not POSIX layers implemented in the runtime.

> But it might not be, or it might have a bug that's triggered by a CR
> with no preceding octet, or some such.)
> No, I'll make that stronger: not just "it wouldn't surprise if it did",
> but even "it would surprise me if it didn't".

I have not used windows for a couple decades, but in my times several
C runtimes defined text mode as \n is \012, \r is \015, on writes
transform \015 to \012\015, on reads discard all \015 ( followed or
not by a \012 ). They did that to avoid needing to keep the last
character when reading, which may have been an important optimization
on the CP/M days, but was not a great thing, and completely mangled
"underline by backspace optimized to underline by carriage return"
used on some files destined to the printer. Others kept context and
transformed \012\015 to \012 and viceversa ( which is trickier than it
seems when the pair straddles a buffer, but not too complex ). One,
particularly, colapsed runs, so AB\012CD\012\015 read in as AB\rCD\n
but ABCD\012\012\012\012\012\015 did as ABCD\n. Windows C runtimes are
complex beasts.

Francisco Olarte.