Greg Ames wrote:
Jeff Trawick wrote:

[EMAIL PROTECTED] 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.




Reply via email to