Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Determine calling function

Reply
Thread Tools

Determine calling function

 
 
Joakim Hove
Guest
Posts: n/a
 
      10-14-2005

Hello,

I have implemented a small library with a function a datatype to
manage temporary storage, and handle out correctly casted storage. The
function to get a double pointer is for instance:

double * work_get_double(work_type *work, size_t size) {}


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(), so if
function foo() calls work_get_double(), and the request can not be
satisfied, I would like work_get_double() to fail with something like:

fprintf(stderr,"Sorry call from function: %s could not satsified. Aborting\n",CALLER_NAME)
abort();

Where CALLER_NAME, in this case would resolve to 'foo'. Is something
like this possible (without actually passing in the function name manually)?


Best Regards

Joakim Hove


--
Joakim Hove
hove AT ntnu.no /
Tlf: +47 (55 5)8 27 13 / Stabburveien 18
Fax: +47 (55 5)8 94 40 / N-5231 Paradis
http://www.ift.uib.no/~hove/ / 55 91 28 18 / 92 68 57 04
 
Reply With Quote
 
 
 
 
Ravi Uday
Guest
Posts: n/a
 
      10-14-2005
You need to explicitly pass the caller name to the function as a
seperate arg !
To get a fn. name at runtime you can use the macro __FUNC__
(implementation dependant)

- Ravi


Joakim Hove wrote:

> Hello,
>
> I have implemented a small library with a function a datatype to
> manage temporary storage, and handle out correctly casted storage. The
> function to get a double pointer is for instance:
>
> double * work_get_double(work_type *work, size_t size) {}
>
>
> 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(), so if
> function foo() calls work_get_double(), and the request can not be
> satisfied, I would like work_get_double() to fail with something like:
>
> fprintf(stderr,"Sorry call from function: %s could not satsified. Aborting\n",CALLER_NAME)
> abort();
>
> Where CALLER_NAME, in this case would resolve to 'foo'. Is something
> like this possible (without actually passing in the function name manually)?
>
>
> Best Regards
>
> Joakim Hove
>
>


 
Reply With Quote
 
 
 
 
Joakim Hove
Guest
Posts: n/a
 
      10-14-2005

Hello,

> You need to explicitly pass the caller name to the function as a
> seperate arg !


OK - I was afraid of that.

> To get a fn. name at runtime you can use the macro __FUNC__
> (implementation dependant)


OK - that is it at least better than fully mannually typing in the
function names. On linux/gcc-3.2.3 the variable __FUNCTION__ is
defined.

Thanks for your help.


Joakim


--
Joakim Hove
hove AT ntnu.no /
Tlf: +47 (55 5)8 27 13 / Stabburveien 18
Fax: +47 (55 5)8 94 40 / N-5231 Paradis
http://www.ift.uib.no/~hove/ / 55 91 28 18 / 92 68 57 04
 
Reply With Quote
 
Emmanuel Delahaye
Guest
Posts: n/a
 
      10-14-2005
Joakim Hove a écrit :
> Hello,
>
>
>>You need to explicitly pass the caller name to the function as a
>>seperate arg !

>
>
> OK - I was afraid of that.
>
>
>>To get a fn. name at runtime you can use the macro __FUNC__
>>(implementation dependant)

>
>
> OK - that is it at least better than fully mannually typing in the
> function names. On linux/gcc-3.2.3 the variable __FUNCTION__ is
> defined.


In C99, __func__ is standard.
 
Reply With Quote
 
ajm
Guest
Posts: n/a
 
      10-14-2005
of course you can "overload" work_get_double by defining a macro that
inserts the __func__ argument on your behalf and encourage users to use
the macro e.g.,

work_get_double_impl(work_type *work, size_t size, const char *caller)
{
....your implementation as it currently is...
}

and then define

#define work_get_double(a,b) work_get_double_impl((a),(b),__func__)

so that when users call work_get_double(a,b) the caller name is passed
"automatically"

the usual function macro caveats apply but the above is not uncommon,

hth,
ajm.

 
Reply With Quote
 
Marc Boyer
Guest
Posts: n/a
 
      10-14-2005
Le 14-10-2005, Joakim Hove <(E-Mail Removed)> a écrit*:
> I have implemented a small library with a function a datatype to
> manage temporary storage, and handle out correctly casted storage. The
> function to get a double pointer is for instance:
>
> double * work_get_double(work_type *work, size_t size) {}
>
> 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(), so if
> function foo() calls work_get_double(), and the request can not be
> satisfied, I would like work_get_double() to fail with something like:
>
> fprintf(stderr,"Sorry call from function: %s could not satsified. Aborting\n",CALLER_NAME)
> abort();
>
> Where CALLER_NAME, in this case would resolve to 'foo'. Is something
> like this possible (without actually passing in the function name manually)?


A common solution is to use macro:
#define WORK_GET_DOUBLE(work, size) work_get_double(work,size,__fun__)

Marc Boyer
 
Reply With Quote
 
Joakim Hove
Guest
Posts: n/a
 
      10-15-2005

Hello,

> A common solution is to use macro:
> #define WORK_GET_DOUBLE(work, size) work_get_double(work,size,__fun__)


thanks to both ajm and Marc for the macro based solution; I see that I
can/will work but I am somewhat (maybe undeservedly so?) weary about
macros.

Joakim

--
Joakim Hove
hove AT ntnu.no /
Tlf: +47 (55 5)8 27 13 / Stabburveien 18
Fax: +47 (55 5)8 94 40 / N-5231 Paradis
http://www.ift.uib.no/~hove/ / 55 91 28 18 / 92 68 57 04
 
Reply With Quote
 
Niklas Norrthon
Guest
Posts: n/a
 
      10-17-2005
Joakim Hove <(E-Mail Removed)> writes:

> Hello,
>
> I have implemented a small library with a function a datatype to
> manage temporary storage, and handle out correctly casted storage. The
> function to get a double pointer is for instance:
>
> double * work_get_double(work_type *work, size_t size) {}
>
>
> 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(), so if
> function foo() calls work_get_double(), and the request can not be
> satisfied, I would like work_get_double() to fail with something like:


OT: Run a debugger like gdb when the program is aborted, and inspect the
call stack.

/Niklas Norrthon
 
Reply With Quote
 
Marc Boyer
Guest
Posts: n/a
 
      10-17-2005
Le 15-10-2005, Joakim Hove <(E-Mail Removed)> a écrit*:
>> A common solution is to use macro:
>> #define WORK_GET_DOUBLE(work, size) work_get_double(work,size,__fun__)

>
> thanks to both ajm and Marc for the macro based solution; I see that I
> can/will work but I am somewhat (maybe undeservedly so?) weary about
> macros.


You can. Macro have a lot of (well ?) known drawbacks, but
sometimes, it is the best (or less worst) compromise.

Marc Boyer
 
Reply With Quote
 
James Dow Allen
Guest
Posts: n/a
 
      10-17-2005

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

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
write a function such that when ever i call this function in some other function .it should give me tha data type and value of calling function parameter komal C++ 6 01-25-2005 11:13 AM
calling virtual function results in calling function of base class... Andreas Lagemann C++ 8 01-10-2005 11:03 PM
calling virtual function results in calling function of base class ... tiwy C++ 0 01-09-2005 11:17 PM
nuby: determine method passed and determine the receiver that received the method Peña, Botp Ruby 1 01-24-2004 07:51 PM
Determine name /path of calling page mg ASP .Net 5 01-02-2004 04:29 PM



Advertisments