Re: [HACKERS] Why the asprintf patch is still breaking the buildfarm

2013-10-23 Thread Tom Lane
David Rowley writes: > On Wed, Oct 23, 2013 at 4:00 AM, 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 possib

Re: [HACKERS] Why the asprintf patch is still breaking the buildfarm

2013-10-23 Thread Tom Lane
Florian Weimer writes: > Do you care about the snprintf behavior on very large buffers (larger > than INT_MAX)? Then there's further complication, and it's an area > where glibc behavior is likely to change in the future (because it is > claimed that C99 and POSIX conflict, and glibc implement

Re: [HACKERS] Why the asprintf patch is still breaking the buildfarm

2013-10-23 Thread David Rowley
On Wed, Oct 23, 2013 at 4:00 AM, 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

Re: [HACKERS] Why the asprintf patch is still breaking the buildfarm

2013-10-22 Thread Florian Weimer
On 10/23/2013 03:05 AM, Noah Misch wrote: 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

Re: [HACKERS] Why the asprintf patch is still breaking the buildfarm

2013-10-22 Thread Tom Lane
Noah Misch 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

Re: [HACKERS] Why the asprintf patch is still breaking the buildfarm

2013-10-22 Thread Noah Misch
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 m

Re: [HACKERS] Why the asprintf patch is still breaking the buildfarm

2013-10-22 Thread Tom Lane
Manlio Perillo writes: > On 22/10/2013 09:58, Tom Lane wrote: >> 1. src/port/asprintf.c exhibits a truly touching faith that vsnprintf will >> report exactly the number of bytes that would have been required, even if >> the buffer is not that large. While this is what is specified in recent >> ve

Re: [HACKERS] Why the asprintf patch is still breaking the buildfarm

2013-10-22 Thread Manlio Perillo
On 22/10/2013 09:58, Tom Lane wrote: So I returned from vacation only to find that the buildfarm has a bad case of acne. All the Windows members are red or pink, and have been for awhile. Sigh. After some research I believe that I understand the reason for the CHECK failures, at least: 1. src

Re: [HACKERS] Why the asprintf patch is still breaking the buildfarm

2013-10-22 Thread David Rowley
On Tue, Oct 22, 2013 at 8:58 PM, Tom Lane wrote: > So I returned from vacation only to find that the buildfarm has a bad case > of acne. All the Windows members are red or pink, and have been for > awhile. Sigh. > > After some research I believe that I understand the reason for the CHECK > fail