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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Nov 26, 2011 at 1:43 PM, Fubo Chen <fubo.chen@xxxxxxxxx> wrote:
> On Sat, Nov 26, 2011 at 12:21 PM, Alexander Nezhinsky
> <alexandern@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux SCSI]     [Linux RAID]     [Linux Clusters]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]

  Powered by Linux