[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Lua Socket
- From: Duck <duck@...>
- Date: Sun, 22 Jul 2007 11:45:26 +1000 (EST)
I am not sure your suggestion fixes these problems.
You're right. It really only ameliorates the "Unix versus DOS" problem. In
other words, it still assumes that there is a single char which uniquely
determines "end of line" (or "end of block of data"), and in that regard
isn't much better than "*l".
I just think that completeness requires that you be able
to reconstruct the input data after receiving it, and it
seems a pity that you can't do that if you want to use
"*l" -- you have to implement your own buffering in Lua on
top of the buffering already implemented below.
This is a nicer request. Maybe I should return the detected
line break as an extra argument?
That was my first thought, except that it isn't enough because recvline()
currently eats _all_ CR characters in the line, not just a final one
before the LF. So the line:
"hello CR gday CR CR LF"
Returning the actual line-break would give:
"hello gday" (+CR)
Neither of these allows the input to be reconstructed.
I guess the most generic way to do this would be to allow a string
matching pattern to be specified, so it would be easy to solve the Mac
versus Unix versus DOS problem," for instance. (Line ends at the first
CRLF, LF alone, or CR alone, which is then consumed and returned with the
But that's getting complicated.