Re: Why the asprintf patch is still breaking the buildfarm
От | David Rowley |
---|---|
Тема | Re: Why the asprintf patch is still breaking the buildfarm |
Дата | |
Msg-id | CAApHDvqUQRohb4ZA3dP22xW6Lus=cUBk1J18Q6asFs5J56gT1Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Why the asprintf patch is still breaking the buildfarm (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Tue, Oct 22, 2013 at 8:58 PM, Tom Lane <tgl@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
В списке pgsql-hackers по дате отправления: