Noah Misch <n...@leadboat.com> writes: > On Tue, Oct 22, 2013 at 11:00:42AM -0400, Tom Lane wrote: >> Yeah. As a separate matter, it might be useful to revise stringinfo.c >> and the asprintf code so that *if* the returned value is larger than the >> given buffer size, we use it as a guide to resizing, avoiding the possible >> need to loop multiple times to make the buffer large enough. And we could >> also improve our own implementation of snprintf to follow the C99 spec. >> >> The point here is that we still need to cope with pre-C99 implementations >> that might return -1 or the given buffer size on overflow. The NetBSD >> implementation doesn't do that, which is reasonable in their context, but >> not workable for us.
> I would vote for choosing the standard we want vsnprintf() to follow (probably > C99) and substituting a conforming implementation wherever "configure" detects > that libc does not conform. We'll be shipping some replacement vsnprintf() in > any case; we may as well use it to insulate the rest of our code from > less-preferred variants. The problem is that we can't tell whether vsnprintf is standard-conforming without a run-time test. That's bad for cross-compiled builds, and it's pretty hazardous even for normal cases, since conceivably an executable built on one machine could be used on another one with different run-time behavior. I'd be willing to take those risks if we got a significant benefit from it, but in this case I don't see much advantage to be had. The code in stringinfo/psprintf wouldn't get very much simpler if we assumed C99 behavior, and we've pretty well isolated the number of places that care to those. (I see a couple places in pg_dump that could be modified to use psprintf instead of direct vsnprintf calls; will go fix.) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers