Re: Why the asprintf patch is still breaking the buildfarm

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Why the asprintf patch is still breaking the buildfarm
Date: 2013-10-22 08:22:22
Message-ID: CAApHDvqUQRohb4ZA3dP22xW6Lus=cUBk1J18Q6asFs5J56gT1Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Oct 22, 2013 at 8:58 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Haribabu kommi 2013-10-22 08:39:46 Re: Heavily modified big table bloat even in auto vacuum is running
Previous Message Tom Lane 2013-10-22 07:58:14 Why the asprintf patch is still breaking the buildfarm