Re: Reasons not to like asprintf - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Reasons not to like asprintf
Date
Msg-id 3471.1382469431@sss.pgh.pa.us
Whole thread Raw
In response to Re: Reasons not to like asprintf  (Stephen Frost <sfrost@snowman.net>)
Responses Re: Reasons not to like asprintf
Re: Reasons not to like asprintf
List pgsql-hackers
Stephen Frost <sfrost@snowman.net> writes:
> I agree that exit/Assert-or-elog is the right API here.  I wonder if
> it'd be reasonable or worthwhile to try and actually make that happen-
> that is to say, we really do only have one implementation for both
> front-end and back-end here, but on the front-end we exit, while on the
> back-end we elog(ERROR).  I'm guessing that's a pipe-dream,

It's not really --- we could make it happen with a single source-file in
libpgcommon, with a few #ifdef FRONTENDs, similarly to exec.c for
instance.  I'm not entirely sure that it's worth the trouble, since once
you take away the error and memory management there's not much left of
these functions; so the #ifdefs might end up being most of the code.
I'm going to go code it shortly, and we'll find out.

> I had been looking at the Assert() that the last character is always
> '\0' in allocStringInfoVA.  Probably a stretch to say that has to be
> upgraded to an elog(), but I'd certainly be much happier with a runtime
> "did this error?" check of some kind than not;

IIRC, that Assert is meant to catch an ancient buggy version of vsnprintf,
so it can't really be replaced by an errno check --- the whole point is
that that vsnprintf failed to recognize it was doing something wrong.
We could upgrade it to an elog; but we had that debate years ago when
the code went in, and I don't think the passage of time has made it more
important rather than less so to have an always-on check for that case.

>> (Hmm ...
>> current POSIX requires *printf to set errno on error, so maybe we could
>> look at errno?)

> Sounds like a good idea to me..  Being explicit about checking for error
> results, rather than hoping-against-hope that the only reason we'd ever
> get a value less than the total length is when we need to provide more
> memory, would be a lot better.  Perhaps it'd be worthwhile to run a test
> against the build farm and see what kind of errno's are being set in
> those cases where we're now getting the 'out of memory' failures you
> mentioned upthread?

Yeah, I'm hoping that reporting errno will give us some more insight,
if anole's problem is still there after we replace the code.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Reasons not to like asprintf
Next
From: Tom Lane
Date:
Subject: Re: Failure while inserting parent tuple to B-tree is not fun