Re: Reasons not to like asprintf

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Reasons not to like asprintf
Date: 2013-10-22 20:36:22
Message-ID: 5326.1382474182@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> Tom Lane wrote:
>> ... BTW, another reason to choose identical APIs for frontend and backend
>> versions of these functions is that it greatly eases use of them in shared
>> frontend/backend code. As I notice somebody has *already done* in
>> common/relpath.c. I'm not exactly sure how those psprintf calls are
>> working at all in frontend builds.

> There's psprintf in src/common/fe_memutils.c, too, using the backend's
> API, which is why this works.

Ah --- that's why it links, anyway. As for "works", I suspect that the
answer is that anole has a vsnprintf that returns -1 on buffer overrun.
vasprintf and then psprintf will interpret that as "out of memory",
resulting in the observed behavior. It'd be interesting to see the stack
trace from that error, though, just to confirm this theory.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2013-10-22 20:38:05 Re: Failure while inserting parent tuple to B-tree is not fun
Previous Message Andres Freund 2013-10-22 20:26:03 Re: Failure while inserting parent tuple to B-tree is not fun