httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@attglobal.net>
Subject Re: cvs commit: httpd-2.0/server protocol.c
Date Thu, 27 Mar 2003 22:08:44 GMT
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.



Mime
View raw message