is it possible to find out the caller of a method programmaticall y

[2pac]

in this scenario
foo1 ---calls---> foo2
is it possible for me to print out - when the control is within foo2 -
the caller of foo2

the information is obviously there in the stack - am wondering if by
some combination of assembly and pointer manipulation - I can print
the name of the caller of the method
Thanks for any suggestions

[Ivan Vecerina]

"2pac" <ca******@yahoo .com> wrote in message
news:d0******** *************** ***@posting.goo gle.com...

in this scenario
foo1 ---calls---> foo2
is it possible for me to print out - when the control is within foo2 -
the caller of foo2

the information is obviously there in the stack - am wondering if by
some combination of assembly and pointer manipulation - I can print
the name of the caller of the method
Thanks for any suggestions

Unfortunately, the only advice that can be given to you is that
there is no standard support for such a functionality in C.
(except if foo1 explicitly receives information about the caller,
as a function parameter or in some global variable).

But yes, in platform-specific ways and in 'debug mode' compiles,
it is typically possible to obtain the information you need from
the call stack. Sometimes a dedicated API is even provided.
But you will have to ask in a forum specific to your platform
(OS, ISA & compiler)...

Regards,
--
http://www.post1.com/~ivec <> Ivan Vecerina

[Mark McIntyre]

On 6 Sep 2003 12:46:09 -0700, in comp.lang.c , ca******@yahoo. com
(2pac) wrote:

in this scenario
foo1 ---calls---> foo2
is it possible for me to print out - when the control is within foo2 -
the caller of foo2

Your debugger can do this, so obviously its possible. However its not
possible in standard C, you'd need to use platform specific debugging
calls. Read your compiler manual, or ask in a group specialising in
it.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.c om/ms3/bchambless0/welcome_to_clc. html>

[E. Robert Tisdale]

2pac wrote:

in this scenario
foo1 ---calls---> foo2
is it possible for me to print out - when the control is within foo2 -
the caller of foo2

the information is obviously there in the stack - am wondering if by
some combination of assembly and pointer manipulation - I can print
the name of the caller of the method
Thanks for any suggestions
cat foo.c #include <stdio.h>

int foo(const char* function, const char* file, int line) {
fprintf(stderr,
"Function foo(const char*, const char*, int)\n"
"called from function %s in file %s at line %d.\n",
function, file, line);
return 0;
}

int main(int argc, char* argv[]) {
foo(__func__, __FILE__, __LINE__);
return 0;
}
gcc -Wall -std=c99 -pedantic -o foo foo.c
./foo

Function foo(const char*, const char*, int)
called from function main in file foo.c at line 12.

[August Derleth]

ca******@yahoo. com (2pac) wrote in
news:d0******** *************** ***@posting.goo gle.com on Sat 06 Sep 2003
01:46:09p:

- I can print
the name of the caller of the method
Thanks for any suggestions

C has no methods. C has subroutines, sometimes called functions by those
who know no better. Methods are parts of object-oriented languages. Maybe
you meant to post this in an Objective-C group, maybe you just need to
learn the vocabulary better.

[Gordon Burditt]

>in this scenario

foo1 ---calls---> foo2
is it possible for me to print out - when the control is within foo2 -
the caller of foo2

the information is obviously there in the stack - am wondering if by
No, it is *NOT* obvious that any function names (addresses, probably,
names, no) appear anywhere in an executable (unless placed there by
the programmer with explicit strings or using __FUNCTION__). Even
if they do, it is not obvious that they are ever loaded into memory
when run normally (that is, not under a debugger). And if the
program is run under a debugger, the debugger knows where the symbols
are, the program doesn't. The debugger also knows the file name of
the executable file, and the program doesn't (unless the programmer
hard-coded a guess in there somewhere).

The symbols aren't necessarily the name of the function, either,
especially in compilers that also support C++, where you can have
multiple functions with the same name.

Oh, yes, there is no portable way for a running program to find a
file name for its own executable file. argv[0] can be of spectacularly
little help, especially under UNIX, where argv[0] and the pathname
of the program to run are independent arguments to exec*() that
need not have any relationship to each other.
some combination of assembly and pointer manipulation - I can print
the name of the caller of the method

C doesn't have methods.

Gordon L. Burdit

[pete]

August Derleth wrote:

C has subroutines, sometimes called functions by those
who know no better.

LOL!

--
pete

[j]

"August Derleth" <li************ *****@onewest.n et> wrote in message
news:Xn******** *************** ***********@63. 223.5.101...

ca******@yahoo. com (2pac) wrote in
news:d0******** *************** ***@posting.goo gle.com on Sat 06 Sep 2003
01:46:09p:

- I can print
the name of the caller of the method
Thanks for any suggestions

C has no methods. C has subroutines, sometimes called functions by those
who know no better. Methods are parts of object-oriented languages. Maybe
you meant to post this in an Objective-C group, maybe you just need to
learn the vocabulary better.

The standard refers to them as ``functions'' or ``function definition(s)'' .
So I don't see how you can say they are referred to as ``functions'' by
those who know no better.

[Jeff]

"j" <ja****@bellsou th.net> wrote in message
news:ny******** *******@bignews 3.bellsouth.net ...

"August Derleth" <li************ *****@onewest.n et> wrote in message
news:Xn******** *************** ***********@63. 223.5.101...

ca******@yahoo. com (2pac) wrote in
news:d0******** *************** ***@posting.goo gle.com on Sat 06 Sep 2003
01:46:09p:

- I can print
the name of the caller of the method
Thanks for any suggestions
C has no methods. C has subroutines, sometimes called functions by those
who know no better. Methods are parts of object-oriented languages. Maybe you meant to post this in an Objective-C group, maybe you just need to
learn the vocabulary better.

The standard refers to them as ``functions'' or ``function

definition(s)'' . So I don't see how you can say they are referred to as ``functions'' by
those who know no better.

I agree with you. I don't think a C programmer will call "subroutine s"
everytime when he is talking about a function.

When we are talking about "function pointer", how should we call it ?

I won't call it "subroutine s pointer" :-)

--
Jeff

[August Derleth]

"j" <ja****@bellsou th.net> wrote in
news:ny******** *******@bignews 3.bellsouth.net on Sun 07 Sep 2003
12:31:00a:

"August Derleth" <li************ *****@onewest.n et> wrote in message
news:Xn******** *************** ***********@63. 223.5.101...

C has no methods. C has subroutines, sometimes called functions by
those who know no better. Methods are parts of object-oriented
languages. Maybe you meant to post this in an Objective-C group, maybe
you just need to learn the vocabulary better.

The standard refers to them as ``functions'' or ``function
definition(s)'' . So I don't see how you can say they are referred to as
``functions'' by those who know no better.

At base, functions are defined by the lambda calculus. This endows them
with properties C subroutines do not possess, such as a first-class status
in the programming language and the ability to be created anonymously
within another function. They are at a higher level of abstraction than
subroutines are.

The Standard apparently doesn't know better, else it would refer to
subroutines as such, or it would extend C subroutines to become functions.
It has done neither, so it apparently doesn't know any better.