httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <...@sunstarsys.com>
Subject Re: source in cvs
Date Mon, 18 Dec 2000 19:49:48 GMT
davidw@prosa.it (David N. Welton) writes:

> Jim Winstead <jimw@trainedmonkey.com> 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.
> 

We're discussing a generic linked-list internal API for doing just 
that (no realloc's though)- I recently posted here a patch to Jim's 
original libapreq implementation at 

http://www.apache.org/~jimw/

The linked list API I'm working on is here

http://www.apache.org/~joes/

I've slightly updated the files at the url above since posting 
the patch. One of the chief goals of the apreq project is to 
make apreq useful for any language that hooks into apache. IMHO
it should be able to build without a perl compiler.

> 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...

It sure better not be :).  I believe it's only modperl related.

> 
> Hrmm also, tmpfile really doesn't cut it, as it doesn't provide the
> filename that it uses.  

It's not supposed to- the file is removed immediately by tmpfile, and
only "exists" as long as the stream to it stays open.

OTOH, it would be quite cool to offer the ability to _safely_ 
pass a q->upload object directly to the filesystem, so no 
additional IO was necessary. It might also be nice to have 
a USE_SFIO directive as well.

> 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.
> 

I'm not sure where this comes from- neither my man pages nor
my glibc2 info documentation say this.  Quite frankly, I'd ignore
it since it's utter BS. On linux, "mkstemp" is just as good as 
"tmpfile" since it's coded as "tmpfile" + "remove" - thus the 
file is gone once the stream to it is closed.  IME, mkstemp works
just fine on linux.

-- 
Joe Schaefer


Mime
View raw message