Re: Determine calling function


Joakim Hove wrote:
> Now, if the work area is not sufficiently large, the function fails,
> with a call to abort. In the case of failure, I would *very much*
> like to know the name of the function calling work_get_double(), ...

Since you plan to *abort* anyway then, assuming abort() doesn't do
any special cleanup or printing, the minimal keystroke approach
which *I* often use is to core-dump.
The function names on the call stack are usually the first thing
printed by a debugger, e.g. in response to "where" when running
gdb. How to coredump? On most systems the simplest approach
would be to *ignore* memory allocation failure and just attempt
to use the (presumably null) pointer!

Of course one would never do things this way in *delivered* code,
but good delivered code probably shouldn't suffer from allocation
failures, at least the kind that lead to abort. I'm guessing
that you're *developing* code that isn't *yet* at the perfection
level you seek.

I'll bet 15-to-1 this message draws very hot flames, but frankly
I find the mantra "Always check malloc()'s return code" to be
very much over-dogmatic in many contexts. (For one thing, an OS
like Linux allows *so much* memory to be malloc()'ed that it will
thrash painfully long before malloc() actually "fails".)

The dogma seems particularly silly in cases like yours where
referencing the invalid pointer achieves *precisely* what you
want: a core dump, with visible call stack, etc.

Detractors will point out that a similar effect can be achieved
without violating the dogma. I reply: Yes, but spend the extra
coding minutes checking for a different error that *might
actually occur*, or where special diagnostic prints might be useful.

Donning my asbestos suit...
James D. Allen

.

Relevant Pages