httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: cvs commit: httpd-2.0/server protocol.c
Date Thu, 27 Mar 2003 22:33:20 GMT
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



Mime
View raw message