On Dec 18, David N. Welton wrote: > Jim Winstead <[EMAIL PROTECTED]> writes: > > this includes the fixed multipart handling code up until before joe > > and i started batting back and forth fixes to the O(n^2) allocation > > in multipart_buffer_read_body. it also includes some fixes and > > changes that were sitting in doug's cvs tree for this. (like > > renaming multipart_buffer.* to apache_multipart_buffer.*.) > > What sort of changes had you discussed? In mod_dtcl's multipart read > routines, I just dumped the Apache routines and used regular > malloc/free, because I could use realloc.
i think joe pointed out the patches he and i cooked up, but it basically amounts to using a linked-list for large non-file post content (basically textareas with more than 5k of text). > > there's also an autoconf setup in there to build the c library > > portion of things. > > It doesn't quite work. There is a 'missing' file missing. Or maybe > just missing knowledge on my part? I don't know the auto* nastynesses > very well. you need to run 'automake -a && autoconf' with a cvs checkout. i removed the generated files from cvs. .tar.gz distributions would contain all the generated files, of course. > How do people feel about removing some of the perlisms, such as > libapreq.pod, and the Changes file. well, the only perlisms about those files are the pod format, i think. we could certainly convert them to another format if that makes everyone feel better. :) > Speaking of which, in the ToDo file, I see: > > o Perl's FILE* typemap leaks! > - randy's win32 patch changes FILE * to PerlIO *. related? > > I hope that that's not actually part of the regular C files... i'm not clear on what exactly randy's patch fixed (i think it was just compile warnings), but don't worry, we really want to support non-perl usage of libapreq, and won't do anything crazy to break that. the original comment (the typemap leaking) is from doug, and i'm not sure what it means. > Hrmm also, tmpfile really doesn't cut it, as it doesn't provide the > filename that it uses. I use mkstemp for mod_dtcl, but the man page > doesn't seem to be very positive: > > Linux: > Don't use this function, use tmpfile(3) instead. It's bet� > ter defined and more portable. > > The one on FreeBSD is a bit nicer. my main concern is avoiding something that would result in a bugtraq notice. :) from browsing around in the php3 source, it looks like that uses tempnam(). of course, the man page for that says "never use this function, use tmpfile() instead". :) php4 uses mktemp/mkstemp. anyone familiar with the accepted secure solution for this? (and we should register a cleanup that automatically removes the file at the end of the request, as joe suggests.) jim
