apr_file_printf - fixed-length buffer and %s

[Chris Knight <Ch...@nasa.gov>]

We recently ran into an issue where we hit the limit of the buffer size
in apr_file_printf. A quick change to apr_file_puts(apr_psprintf(...
fixed the problem but it got me thinking:

1) The apr_file_io.h should mention this limitation. (It became obvious
after we noticed that apr_file_printf was not needing a pool.)

2) It seems to me that, with a rewrite, the buffer should only be
necessary for formatting numerical expansions (i.e. %03.2d) and that the
format string and "%s" expansions could be written directly to the file
and bypass a buffer. This should improve performance and ensure that the
buffer size limit is not an issue. (And a smaller buffer should be
acceptable?) I would be willing to take this re-write on, if I get the
blessing of the apr developers...

Re: apr_file_printf - fixed-length buffer and %s

[Chris Knight <Ch...@nasa.gov>]

Chris Knight wrote:

> 2) It seems to me that, with a rewrite, the buffer should only be
> necessary for formatting numerical expansions (i.e. %03.2d) and that the
> format string and "%s" expansions could be written directly to the file
> and bypass a buffer. This should improve performance and ensure that the
> buffer size limit is not an issue. (And a smaller buffer should be
> acceptable?) I would be willing to take this re-write on, if I get the
> blessing of the apr developers...

In fact, this is a very easy thing to re-write, using the apr_vformatter 
code, a fixed-size buffer (moderately-sized) and the flush would simply 
write the buffer to the file. Any interest in my providing the patch?

Re: apr_file_printf - fixed-length buffer and %s

[Chris Knight <Ch...@nasa.gov>]

FYI, I've added a bugzilla bug and attached a patch to 
apr/file_io/unix/readwrite.c that fixes this problem. (I'm assuming the 
code could also be copied for other platforms?)

Chris Knight wrote:

> We recently ran into an issue where we hit the limit of the buffer size
> in apr_file_printf. A quick change to apr_file_puts(apr_psprintf(...
> fixed the problem but it got me thinking:
>
> 1) The apr_file_io.h should mention this limitation. (It became obvious
> after we noticed that apr_file_printf was not needing a pool.)
>
> 2) It seems to me that, with a rewrite, the buffer should only be
> necessary for formatting numerical expansions (i.e. %03.2d) and that the
> format string and "%s" expansions could be written directly to the file
> and bypass a buffer. This should improve performance and ensure that the
> buffer size limit is not an issue. (And a smaller buffer should be
> acceptable?) I would be willing to take this re-write on, if I get the
> blessing of the apr developers...