On Feb 19, 2014, at 22:30, the Great Sean Conner wrote:
My modifications do not harm Windows and "text" mode files in any way.
The modifications only make sure whatever is returned by the C library
is actually passed to the Lua string.
Most programs open all files in binary mode on Windows anyway, to
avoid exactly this surprises anyway. And with the binary mode flag
DOS behaves like modern Unix and Mac OS X implementations behave
And to contribute to your anecdotes about this infamous text mode, I
have seen multiple Windows program bugs due to this - including
a scan program that failed to open JPEG files when imported with
one menu entry (but not other functions) because at that code path
the file was not opened in binary mode. So \r\n was translated to
just \n and thus obviously corrupted the JPEG stream while reading.
Many people consider this non-binary text mode harmful and make
sure the binary mode flat is never forgotten when files are opened
for portable software that eventually runs on such DOS and alike
Again, my proposed changes do not harm Windows. The Lua
code before already check for the trailing \n, and so do my
changes. So no new problem due to that. The only change is
that all data returned by the C function is actually added to
the Lua string. And again we only need to do additional hiccup
because this really old C function does not return the actual
written data directly. This is why the Lua code already had to
scan for the trailing 0. Just that the trailing 0 is not the real
indicator of bytes written.
With a more proper C function API like the Posix getline there would
not be the need for any of this and the actual length would be
directly returned already:
ssize_t getline(char **lineptr, size_t *n, FILE *stream);
Great. My code does not alter any of this. If the C run-time of those
ancient systems does not handle this internaly the frets function, than
the current Lua implementation may probably already return random
garbage at the end, as the current implementation is scanning for \0
and checking for \n to read more.