Re: io:lines() and \0

[Sean Conner <sean@...>]

It was thus said that the Great René Rebe once stated:
> 
> On Feb 21, 2014, at 10:00 , Sean Conner wrote:
> 
> >  But, LPeg aside, there are other ways of reading in the data.  One: if
> > Content-Length: exists, convert the value to an integer, and pass that to
> > f:read(), which will read that many bytes of data (using the C function
> > fread()).  If the Content-Length: header doesn't exist, and the
> > Content-Transfer-Encoding: header indicates 8bit, then yes, you have an
> > issue, and one that can be solved without patching Lua, by writing a C
> > module to Do The Right Thing.  Because even *if* the Lua team accept your
> > proposal, at best, it'll be placed on the Lua bugs page and won't become a
> > part of Lua until the next official release X years from now (that might be
> > fine if you are not planning on releasing your code and have a locally
> 
> And because it may take some time to get into an official release we now stop
> fixing bugs and improvements?

  No, but the bug fixes for Lua aren't immediately applied to the current
release version of Lua.  If your code relies upon the fix, and others can
use your code, it is then upon them to make sure the Lua they use has the
patch applied, which may or may not be the case.  But it sounds to me as if
you don't really indend for your code to be used by others, so that point is
moot.

> Because some core function does not behave as expected we should all
> suffer and apply complex and hard to read and follow workarounds like your
> LPeg example?

  Some of us are arguing that the core function does behave as expected
(perhaps because of a longer historical outlook at how things were when C
was standardized; perhaps because some of us consider binary files as
incapable of being read "line by line" because the concept of a "line" in a
binary file seems incongruous).

  As for the LPeg example, it's how I solved the issue and why I wasn't hit
by embedded NUL bytes in CGI uploads.  If you don't want to use LPeg, fine
by me.  I did point out some other alternatives though.

> > patched Lua; anyone else that wants to use your code will need to have a
> > patched Lua).  And don't forget about LuaJIT (different team).  It probably
> > suffers from the same issue.
> 
> What changes LuaJIT picks from vanilla Lua is a separate issue, AFAIR so far
> not even all 5.2 features made it into it. Since when does Roberto only make
> changes to Lua when Mike approves them as well?

  I mentioned LuaJIT because it's another implementation of Lua that
probably suffers from the same problem.  It wasn't entirely clear that you
were talking about a codebase that uses Lua 5.2 (some of us still use Lua
5.1 for a variety of reasons [1]) or a codebase that you alone were using.  

  -spc (Who personally would love if Lua used C99, but knows that won't
	happen any time soon ... )

[1]	I do.  Why?  Because of the existing codebase at work.  Converting
	it to use Lua 5.2 would require enough changes that I'd rather not
	have to do the extensive testing required (since the code exists to
	test our main product, which is already difficult to test).