is it possible to find out the caller of a method programmatically

2

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
 
I

Ivan Vecerina

2pac said:
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,
 
M

Mark McIntyre

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.
 
E

E. Robert Tisdale

2pac said:
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.
 
A

August Derleth

(e-mail address removed) (2pac) wrote in
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.
 
J

Jeff

j said:
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 "subroutines"
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 "subroutines pointer" :)
 
J

j

August Derleth said:
(e-mail address removed) (2pac) wrote in
46:09p:


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.
 
A

August Derleth

31:00a:
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.
 
J

Jack Klein

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

You may think that "the information is obviously there in the stack",
and you might even be right on many platforms. But C does not require
a stack and does not even use one the way you think it does even on
all architectures that provide one in hardware.

When your function begins execution on an ARM processor, for example,
the return address is in what is called the "link register", not on
the stack at all.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq
 
J

Jack Klein

(e-mail address removed) (2pac) wrote in
46:09p:


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.

C has functions, it does not have subroutines.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq
 
J

Jack Klein

31:00a:


At base, functions are defined by the lambda calculus. This endows them

Perhaps in your mind. In C, functions are defined by ANSI/ISO/IEC
9899, and before that by K&R.
with properties C subroutines do not possess, such as a first-class status

C functions posses the properties that the C standard defines.
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.

You are free to use whatever terminology you like. Unfortunately that
makes you irrelevant here.
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.

Apparently you don't know better. A C function is a function because
the C standard defines it as such. Whether or not it meets your idea,
derived from other languages or any other sources, of what a function
should be, is immaterial. Unless a document with such definitions is
referenced as normative in the C standard, it is meaningless in this
context.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq
 
M

Mark Gordon

31:00a:


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.

No, functions are defined by the relevant documentation just like any
other term. For instance one of the functions of my mobile phone is
taking voice memos, something which has nothing to do with programming
languages at all. Just one instance of the word function not meaning
what you claim is its only meaning.
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.

The standard doesn't know anything, it is a document. However the people
who wrote the standard do know what they are talking about and have
based their definition of a C function on one of the common definitions
(in the programming world) of the word function.
 
M

Mark McIntyre

31:00a:


At base, functions are defined by the lambda calculus.

yeah, whatever. Pop over to comp.programming if you want to debate the
meaning of the word "function".
Here, we use the one implied from the ISO standard. 5.1.2.2.1 and
7.anything provide a pretty simple examples, and if they don't have
"lambda calculus" whatever that is (please don't tell me), then your
definition, which may be correct in some abstract sense, is
irrelevant.
The Standard apparently doesn't know better,

ROFL !
 
J

Jeff

August Derleth said:
31:00a:


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.

What ? functions are defined by the lambda calculus ??

We are talking about "C language" here, and it is defined by the ISO
standard, and the standard is always "Correct" and "Authoritative" for the C
language. The meaning of "function" is defined by the standard, and it is
NOT open for debate.

The other meaning of "function" is off-topic here.
 
A

August Derleth

07:28p:
"lambda calculus" whatever that is (please don't tell me),

I pity any programmer who is innocent of the lambda calculus, and I pity
any person who is innocent of the desire to learn. Both are mentally
crippled.
 
A

August Derleth

11:58p:
Perhaps in your mind. In C, functions are defined by ANSI/ISO/IEC
9899, and before that by K&R.

And in the rest of the programming and mathematical world, they are
defined by Alonzo Church. I think that takes precedent over any flavor-of-
the-month standard.
C functions posses the properties that the C standard defines.

But C functions are not functions. You cannot call bicycles `Bavarian
Copying Machines' because they cannot be considered any subset of the
class of copying machines, proper or improper.
You are free to use whatever terminology you like. Unfortunately that
makes you irrelevant here.

Again, the Humpty Dumpty logic strikes back. Words have meaning beyond
what you say, and they have context beyond what the Standard defines. If
the Standard's definition is at variance with the rest of the world, the
Standard is wrong.

After all, (1==0) must always evaluate to false. Even if a future Standard
allows it to evaluate to true, even if a future Standard requires it
evaluate to true.
Apparently you don't know better. A C function is a function because
the C standard defines it as such.

Humpty Dumpty logic, Humpty Dumpty language.
Whether or not it meets your idea,

Not my idea. The mathematical idea, and the idea followed by other
programming languages.
derived from other languages or any other sources, of what a function
should be, is immaterial.

Hardly immaterial. If we cannot agree on proper terminology, we might as
well abandon all pretense of rational communication.

Functions were defined long before C was, and they will survive long after
C is relegated to the dustbin of history.
Unless a document with such definitions is
referenced as normative in the C standard, it is meaningless in this
context.

This context is a subset of a larger mathematical context, one in which
functions have a precise definition the Standard is innocent of.
Therefore, there exists a variance, or a logical inconsistency. In all
cases of such a variance, something is correct and something is incorrect.
As the notion of a Standard upending nearly a century of mathematical
thought is absurd, the Standard must be incorrect.
 
R

richard

Hardly immaterial. If we cannot agree on proper terminology, we might as
well abandon all pretense of rational communication.

You might ponder this statement in the context of speaking about c, for which
the standard defines proper terminology.

Your post is off topic if you don't want to talk about standard c using standard
terminology or you're a troll or both.
 
K

Kevin Easton

August Derleth said:
This context is a subset of a larger mathematical context, one in which
functions have a precise definition the Standard is innocent of.
Therefore, there exists a variance, or a logical inconsistency. In all
cases of such a variance, something is correct and something is incorrect.
As the notion of a Standard upending nearly a century of mathematical
thought is absurd, the Standard must be incorrect.

It is quite common for words in English to have more than one meaning,
which must be disambiguated by context. This is particularly the case
in technical fields, and doubly so in computing.

The user manual for my DVD player describes "an auto power off function"
- should I complain that it is using the word in a sloppy manner? The
word function has a different, widely understood meaning in the context
of C, with a history of over 20 years.

Luckily, the human brain has incredible pattern-recognition.. err..
functionality... so determining the intended meaning of a word from
the context is a task we're all well-equipped for.

- Kevin.
 
P

pete

August said:
11:58p:


And in the rest of the programming and mathematical world, they are
defined by Alonzo Church.
I think that takes precedent over any flavor-of- the-month standard.

Not on the flavor of the month newsgroup.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top