[stgt] [PATCH 1/4] struct concat_buf and concat_printf() for printing to buffers

Alexander Nezhinsky alexandern at mellanox.com
Sun Nov 27 09:12:31 CET 2011


On Sat, Nov 26, 2011 at 1:43 PM, Fubo Chen <fubo.chen at gmail.com> wrote:
> On Sat, Nov 26, 2011 at 12:21 PM, Alexander Nezhinsky
> <alexandern at mellanox.com> wrote:
> > Text queries issued through tgtadm use a fixed-size buffer that is filled,
> > step by step, typically by a few calls to snprintf() or an equivalent.
> > This requires tracking the current position within the buffer and guarding
> > against overflows.
>
> Looks like a duplicate of asprintf() ? See also
> http://www.gnu.org/s/libc/manual/html_node/Dynamic-Output.html.

As far as i understand asprintf() always allocates a new buffer to accommodate the
printed string. This would have been an ideal solution if we had called snprintf
always only once not knowing the output length in advance. But we regularly
call it few times and concatenate the output strings.
If anything, we could use another mechanism appearing on the same manual page
that you sent: obstack. 

But i guess that even a better option would be a string stream opened by 
open_memstream():
http://www.gnu.org/s/hello/manual/libc/String-Streams.html#String-Streams

I thought to defer this for a later stage, as concat_buf can encapsulate whatever
mechanism we choose, probably with some changes to its init function (no buffer
and size supplied by user in case we use a stream stream or a like and do not
realloc by ourselves). 

Tomo, what do you think? I can rewrite the patches to use a stream - or we can
decide later and do it in two leaps. 

Alexander--
To unsubscribe from this list: send the line "unsubscribe stgt" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html



More information about the stgt mailing list