httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Winstead <>
Subject Re: source in cvs
Date Mon, 18 Dec 2000 21:12:23 GMT
On Dec 18, David N. Welton wrote:
> Jim Winstead <> 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.)


View raw message