Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Errors-To: <wrowe@rowe-clan.net>
Message-Id: <5.2.0.9.2.20030327163308.01871e98@pop3.rowe-clan.net>
Date: Thu, 27 Mar 2003 16:33:20 -0600
To: dev@httpd.apache.org
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
Subject: Re: cvs commit: httpd-2.0/server protocol.c
In-Reply-To: <3E83766C.7010708@attglobal.net>
References: <3E8371AA.5060204@apache.org>
 <20030327203456.22153.qmail@icarus.apache.org>
 <3E836B47.8010600@attglobal.net>
 <3E8371AA.5060204@apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 04:08 PM 3/27/2003, you wrote:
>Greg Ames wrote:
>>Jeff Trawick wrote:
>>
>>>gregames@apache.org wrote:
>>>
>>>>gregames    2003/03/27 12:34:56
>>>>
>>>>  Modified:    server   protocol.c
>>>>  Log:
>>>>  ap_rgetline_core: set the number of bytes read & copied into the caller's
>>>>  buffer when returning APR_ENOSPC.  This prevents seg faults in
>>>>  ap_get_mime_headers_core in an error path which handles headers that are too
>>>>  long.
>>>>    Submitted by:    Jeff Trawick
>>>
>>>
>>>unclear; see below :)
>>>
>>>>  @@ -390,6 +391,7 @@
>>>>               last_char = *s + bytes_handled - 1;
>>>>           }
>>>>           else {
>>>>  +            *read = n;
>>>
>>>
>>>
>>>I thought this should be
>>>
>>>                 *read = bytes_handled;
>>>
>>>since bytes_handled tells how many bytes were successfully copied to the caller's buffer, whereas n just tells how big the callers buffer is
>>>(or am I confused???)
>>
>>Back up to the "if" statements that correspond to these two else's. bytes_handled is bigger than the size of the caller's buffer in these two cases, unless I missed something.  It seems safer to go with the smaller of the two.
>
>After reading it again it looks like bytes_handled and n are always exactly the same in these two error paths.
>
>I had coded it as "*read = bytes_handled" because bytes_handled is the number of bytes already coded and available for the caller to look at. But "*read = n" is just as correct from a different perspective.
>
>I remove my concern and will +1 the patch.

And +1 here too.

Bill