On Feb 21, 2014, at 10:31 , Sean Conner wrote:
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
I did not imply that. It should be obvious that bug fixes / improvement are
always only available in a future release, ...
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).
Text files on DOS can still store \0 and this function does not return what
the C function returns, and why should it be artificially be limited?
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.
Yes, we mostly still use Lua 5.1, too The function is mostly the same and the
changes apply more or less there too (my first patch even applied 1:1 to it).
However being polite I did the work for improvements on the latest upstream
release. Our 5.1 copy now has my last patch as fix for this.
-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).
