On Tue, Oct 30, 2001 at 11:02:56AM +0300, Alexander V. Lukyanov wrote:
Originally, I used memmove/memchr for speed--they're well-optimized. In
retrospect, that's also iterating over the input buffer twice (though in
a cache-friendly way.)
Here's one that anyone can understand:
This
On Tue, Oct 30, 2001 at 04:17:20AM -0500, Glenn Maynard wrote:
This one is nicer indeed. And smaller. It has a bug but it does not matter.
Er, what is it? Passed my tests (leading, trailing, consecutive \r\n
with or without null terminator.)
My mistake, no bug. I has overlooked the
On Sat, Oct 27, 2001 at 03:17:02PM -0400, Glenn Maynard wrote:
Originally, I used memmove/memchr for speed--they're well-optimized. In
retrospect, that's also iterating over the input buffer twice (though in
a cache-friendly way.)
Here's one that anyone can understand:
This one is nicer
I have applied the patch. Some notes below.
On Fri, Oct 26, 2001 at 02:41:28PM -0400, Glenn Maynard wrote:
Important: I don't know what EPLF is and have no means of testing that code
change. Do you have a server I could use to test it?
Here is one server: ftp://vgsn.glasnet.ru. There are
On Sat, Oct 27, 2001 at 02:56:07PM +0400, Alexander V. Lukyanov wrote:
I've rewrote crlf_to_lf so it is more clear and easier to understand.
int crlf_to_lf(char *buf, int s)
{
char *store=mem_crlf(buf,s);
if(!store)
return s;
int retsize=s-1;
s-=store+1-buf;
Added --with-profiling, since I was tired of manually editing the
makefile. :) Adds -pg and suppresses LDFLAGS -s.
Ascii mode is extremely slow; this affects ls, too. This is because of
the data pipeline in ASCII mode: every line tends to cause a full
scheduling loop. Fixed this in a couple
