On Dec 11, Joe Schaefer wrote: > I just got an account with apache.org (user joes). Have you > been able to get a CVS tree going for apreq at apache.org?
close. i've got doug's cvs tree, now i just have to wait for brian to fix the permissions on a directory and then integrate the stuff we've been working on. there's also new apreq-dev and apreq-cvs mailing lists (@httpd.apache.org, ezmlm-managed like the mod_perl lists). i've cc'd this there so it appears in the ezmlm archives. > I put together a preliminary list.c/list.h API for > dealing with dynamically resizing buffers. It's tailor > made for handling most of the cumbersome problems that > we face with implementing multipart/form-data posts. I'd > appreciate feedback on how to improve it (one thing > I'm considering is a direct BUFF interface.) The > files are located at cool. i haven't had a chance to dig in yet, but it sounds great at first glance. i wouldn't worry about a direct BUFF interface, since one of the ToDo items is to port to apache-2.0, and BUFF is gone in 2.0. :) it may be worth looking at the 'ring' code from apr-util at http://www.apache.org/websrc/viewcvs.cgi/apr-util/include/ap_ring.h. > 2) There seems to be an accounting error at the end of > multipart_buffer_read. On a terminal CRLF, it should > reduce the return value by one more (--len): good catch. > Also, one serious problem with your last patch: the arrows > in your linked list point the wrong way :) I have a patch > to fix this, but obviously I'd prefer it if we incorporated > the list.[ch] code I wrote to specfically deal with these > issues. d'oh! i made sure i had the arguments to memcpy() the right way 'round (they weren't initially), but i missed that. shows you how much testing i did to check it was correct versus uses less memory. :) jim
