On Tue, Oct 22, 2013 at 8:58 PM, Tom Lane <t...@sss.pgh.pa.us> 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/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 > versions of the POSIX standard, older platforms have much sketchier > behavior. > > 2. In particular, our own src/port/snprintf.c follows the SUS v2 rule that > it should report the number of bytes it *actually wrote*. This means > that asprintf.c will never think that its initial 128-byte allocation was > insufficient. So, on platforms where we use this implementation (notably > including Windows), the result of any asprintf call is effectively > truncated at 128 bytes. > > Thanks for looking at this. I had a bash and trying to figure out why vcregress check would not work last night and didn't get very far... I can confirm that you are right just by changing the 128 into 12800 and compiling, vcregress check worked after that. Regards David Rowley > > I have a lot of other gripes about this whole patch, but they can > wait till tomorrow. > > 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 >
