Oops, here's another one:
--- c/apache_multipart_buffer.cSun Dec 17 01:36:38 2000
+++ c/apache_multipart_buffer.c Tue Dec 19 00:25:45 2000
@@ -289,7 +289,7 @@
/* copy the data */
memcpy(buf, self->buf_begin, len);
buf[len] = 0;
- if(bound && len > 0 && buf[l
On Dec 18, Matt Sergeant wrote:
> Can I also add in the very minor patch to do singletons? I'll send a patch
> to the list later today so you can see its very unintrusive...
seems harmless enough. i want to address this at the basic c level
eventually, but i don't see any harm in doing it at the p
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
On Dec 17, Joe Schaefer wrote:
> Jim Winstead <[EMAIL PROTECTED]> writes:
>
> > it would be good to get a libapreq-0.32 out there soon. should we
> > do it before or after addressing multipart_buffer_read_body?
>
> "Before" sounds fine to me, so long as people are aware that you
> might need to m
its no problem just sending patches here, but there's no harm in
just getting added to the httpd group, since this is a sub-project
of the httpd group, and you won't actually have cvs commit access
to anything beyond the httpd-apreq repository.
(i commited this patch.)
jim
On Dec 18, David N. We
I am not part of the httpd group (as I haven't done work on the
server), and it's ok with me to submit patches here. If that's
problematic, I suppose it won't hurt to have me as part of the httpd
group.
--
--- c/apache_cookie.c 2000/03/30 06:10:27 1.6
+++ c/apache_cookie.c 2000/1
[EMAIL PROTECTED] (David N. Welton) writes:
> Joe Schaefer <[EMAIL PROTECTED]> writes:
>
> Fair enough, but with mkstemp, I can do that after the script has had
> a crack at doing something with the file.
Do you install a cleanup handler or something? Is there some source
code I could look at?
Joe Schaefer <[EMAIL PROTECTED]> writes:
> mkstemp doesn't remove the temp file, but tmpfile _does_.
> > I don't know... I like the idea of giving someone a filename and
> > letting them do what they want with it, which may or may not
> > include opening the file.
> But if they do nothing with i
[EMAIL PROTECTED] (David N. Welton) writes:
> Joe Schaefer <[EMAIL PROTECTED]> writes:
>
> > 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
> > "t
Joe Schaefer <[EMAIL PROTECTED]> writes:
> 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 t
[EMAIL PROTECTED] (David N. Welton) writes:
> 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 a
On Dec 18, Matt Sergeant wrote:
> cvs server: Updating httpd-apreq/Cookie
> cvs server: failed to create lock directory for
> `/home/cvs/httpd-apreq/Cookie' (/home/cvs/httpd-apreq/Cookie/#cvs.lock):
> Permission denied
> cvs server: failed to obtain dir lock in repository
> `/home/cvs/httpd-apreq/C
On Sat, 16 Dec 2000, Jim Winstead wrote:
> as you know if you're on the apreq-cvs mailing list, i've put the
> libapreq code in the httpd-apreq module in cvs. to check it out:
>
> cvs -d:ext:[EMAIL PROTECTED]:/home/cvs co httpd-apreq
cvs server: Updating httpd-apreq
U httpd-apreq/.cvsignore
U h
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 t
On Sat, 16 Dec 2000, Jim Winstead wrote:
> as you know if you're on the apreq-cvs mailing list, i've put the
> libapreq code in the httpd-apreq module in cvs. to check it out:
>
> cvs -d:ext:[EMAIL PROTECTED]:/home/cvs co httpd-apreq
>
> this includes the fixed multipart handling code up until b
Jim Winstead <[EMAIL PROTECTED]> writes:
> it would be good to get a libapreq-0.32 out there soon. should we
> do it before or after addressing multipart_buffer_read_body?
"Before" sounds fine to me, so long as people are aware that you
might need to make some minor changes to the header files (e
as you know if you're on the apreq-cvs mailing list, i've put the
libapreq code in the httpd-apreq module in cvs. to check it out:
cvs -d:ext:[EMAIL PROTECTED]:/home/cvs co httpd-apreq
this includes the fixed multipart handling code up until before joe
and i started batting back and forth fixes
17 matches
Mail list logo
