From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Noah Misch <noah(at)leadboat(dot)com> |
Cc: | Manlio Perillo <manlio(dot)perillo(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Why the asprintf patch is still breaking the buildfarm |
Date: | 2013-10-23 01:51:42 |
Message-ID: | 11226.1382493102@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Noah Misch <noah(at)leadboat(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2013-10-23 02:07:27 | Sigh, my old HPUX box is totally broken by DSM patch |
Previous Message | Josh Kupershmidt | 2013-10-23 01:37:13 | Re: Re: [BUGS] BUG #7873: pg_restore --clean tries to drop tables that don't exist |