Re: io:lines() and \0

[Sean Conner <sean@...>]

It was thus said that the Great René Rebe once stated:
> 
> Given this IO function may not be the most performance critical code path
> in Lua, that may be acceptable. But your milage may vary; and so I get the
> feeling nobody will like it here in any case.

  You really should be testing this under Microsoft Windows.  Windows
definitely treats text and binary files differently than Unix.  For
starters, you will never get a '\r' (CR, or character 13) in text mode.  You
will never see SUB (charater 26) in text mode---and most likely, you won't
see *any* input past SUB (you'll just get an EOF marker) [1].  This is just
a few reasons why treating a binary file as text is problematic.  [5]

  -spc (I don't care to support Windows, and you may not care to support
	Windows, but there are some here who do care ... )

[1]	Some older, simpler operating systems [2] never bothered storing the
	actual length of a file on disk, but rather, just indicated the
	number of blocks (or rather, disk sectors) the file used (or even
	worse---linked blocks together, so getting a "size" of a file was a
	very expensive operation).  All files were multiple sector sizes. 
	For text files (or text-like files) where not all of the last sector
	was actually used, a marker byte was used to indicate the actual end
	of file [4] if it mattered.  The byte used depended upon the
	operating system (or even just a convention, not a real standard).

[2]	Say, CP/M, the direct ancestor of MS-DOS [3].

[3]	Which is the direct ancestor of Microsoft Windows.

[4]	Executable files never had this marker, so executable sizes were
	always divisible by the default sector (or block) size.  Other
	binary formats could contain a field for the actual size, but it was
	up to the format.  The operating system didn't care.

[5]	Yes, it just works under Unix.  But that's because Unix treats all
	files as a sequence of bytes.