As to the pointfulness of doing so, ISTM unlikely that the knowledge (of
which function was calling b_a_f) on its own would ever be enough for
someone to fix a bug, so the usefulness of supplying that knowledge on its
own (by letting b_a_f return NULL) seems dubious to me. I suppose that some
bugs might be so immediately obvious from the source code of the calling
function that just eyeballing it is enough to fix them, but I rather expect
that >95% of bugs will require someone to get out the debugger and have it
breakpoint at the failure, and at that point you get to see not just what
the calling function is but also all its internal variables, arguments it
was called with, etc etc.
So it's supplying information that, while valid, is unlikely to ever be of
any actual help, at the cost of perhaps-sometimes-maybe invoking undefined
behaviour on some systems.
Anyway, that's my take on it. 2c and all that. But it's all rather
academic, and I don't think it matters a _great_ deal which solution is
applied in the end. I'm happy with the abort, but basically the only *hard*
requirements I'd put on the solution myself are that it mustn't silently
generate invalid output files, and it should make it clear that the error is
an internal coding error requiring debugging, rather than one caused by (eg)
bad inputs.