On Tue, 2007-07-31 at 15:57 +0100, Johannes Schindelin wrote:
> 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@xxxxxxxxxx> 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
