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
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 |