Re: [PATCH 3/5] Add strbuf_printf() to do formatted printing to a strbuf.
- From
Kristian Høgsberg <krh@redhat.com>
- Date
- Jul 31, 2007, 15:28 UTC
- Message-ID
- <1185895733.11086.54.camel@hinata.boston.redhat.com>
- In-Reply-To
- <Pine.LNX.4.64.0707311556150.14781@racer.site>
On Tue, 2007-07-31 at 15:57 +0100, Johannes Schindelin wrote:
Show 21 quoted lines
> Hi,
>
> On Tue, 31 Jul 2007, Kristian H?gsberg wrote:
>
> > On Mon, 2007-07-30 at 21:36 -0700, Junio C Hamano wrote:
> > > Kristian Høgsberg <krh@redhat.com> writes:
> > >
> > > > +void strbuf_printf(struct strbuf *sb, const char *fmt, ...)
> > > > +{
> > > > + char one_line[2048];
> > > > + va_list args;
> > > > + int len;
> > >
> > > Such a nice abstraction so far, and then at the highest level of
> > > callchain we have this hardcoded limit?
> >
> > Yeah, I know, it sucks. I'd like to just run vsnprintf with a 0-sized
> > buffer to get the length, and then grow the buffer by that much, but
> > that's not very portable as far as I know.
>
> We do have nfvasprintf()...Ah, ok... it looks like it's using the second approach I described: printing into a temp buffer, and realloc'ing and printing again if it didn't fit. But it dies with 'out of memory' if vsnprintf returns < 0, is that reasonable? I'm not familiar with what will make vsnprintf return a negative value... Also, that implementation potentially uses the va_list twice, which isn't universally supported. C99 introduces va_copy for this case, but that's also not available everywhere.
However, if the nfvasprintf implementation in trace.c is fine, I'll just use that approach in strbuf_printf too. I'd just like to know that the above issues aren't a problem on win32, since part of my motivation for doing this is to make git available on windows so it will be easier for people to choose git.
Kristian