ap_vformatter (Apache 1.3) patch reversal

[Jim Jagielski]

I think that the below needs to be taken out of ap_vformatter in 1.3.26...
IIRC, it was a back-port of a 2.0 specific bug, regarding apr_psprintf().
This also gets rids of the bogusness of: It's not possible to
distinguish between an output which was truncated, and an output
which exactly filled the buffer which this patch caused.

Comments?

Index: src/ap/ap_snprintf.c
===
RCS file: /home/cvs/apache-1.3/src/ap/ap_snprintf.c,v
retrieving revision 1.51
diff -u -r1.51 ap_snprintf.c
--- src/ap/ap_snprintf.c14 Mar 2002 12:08:06 -  1.51
+++ src/ap/ap_snprintf.c6 Sep 2002 19:55:29 -
@@ -1158,10 +1158,6 @@
fmt++;
 }
 vbuff-curpos = sp;
-if (sp = bep) {
-   if (flush_func(vbuff))
-   return -1;
-}
 return cc;
 }
 

-- 
===
   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
  A society that will trade a little liberty for a little order
 will lose both and deserve neither - T.Jefferson

Re: ap_vformatter (Apache 1.3) patch reversal

[Jim Jagielski]

Jim Jagielski wrote:
 
 I think that the below needs to be taken out of ap_vformatter in 1.3.26...
 IIRC, it was a back-port of a 2.0 specific bug, regarding apr_psprintf().
 This also gets rids of the bogusness of: It's not possible to
 distinguish between an output which was truncated, and an output
 which exactly filled the buffer which this patch caused.
 
 Comments?
 

This implies, of course, that the real fix to 9932 is implemented, ala
what was done with apr_vformatter and psprintf_flush.

-- 
===
   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
  A society that will trade a little liberty for a little order
 will lose both and deserve neither - T.Jefferson