By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,413 Members | 999 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,413 IT Pros & Developers. It's quick & easy.

standard way to determine depth in stack

P: n/a
I can't see to easily find this on google or in a newsgroup

Is there a standard function/macro/whatever you can call and determine
the distance in a C program how deep one is in the C call stack from
main.

Something along the lines:

int main()
{
int i = stackdepth();
f2()
}

here i == 0.

void f2()
{
int i = stackdepth();
}

here i == 1

and so on.

I'm interested in nonstandard ways (if a standard way does not
suffice), or any crazy ideas.

Feb 21 '07 #1
Share this Question
Share on Google+
13 Replies


P: n/a
so**********@gmail.com wrote:
I can't see to easily find this on google or in a newsgroup

Is there a standard function/macro/whatever you can call and determine
the distance in a C program how deep one is in the C call stack from
main.
No - as some people here enjoy pointing out, there might not be a stack!
>
I'm interested in nonstandard ways (if a standard way does not
suffice), or any crazy ideas.
For those, you should ask on a forum for your compiler and or OS.

--
Ian Collins.
Feb 21 '07 #2

P: n/a
softwaredoug writes:
Is there a standard function/macro/whatever you can call and
determine the distance in a C program how deep one is in the C
call stack from main.
There is no standard way. It depends on your operating system and
possibly your compiler. Ask in a group for programming in your OS.

--
Regards,
Hallvard
Feb 21 '07 #3

P: n/a
so**********@gmail.com a écrit :
I can't see to easily find this on google or in a newsgroup

Is there a standard function/macro/whatever you can call and determine
the distance in a C program how deep one is in the C call stack from
main.

Something along the lines:

int main()
{
int i = stackdepth();
f2()
}

here i == 0.

void f2()
{
int i = stackdepth();
}

here i == 1

and so on.

I'm interested in nonstandard ways (if a standard way does not
suffice), or any crazy ideas.
You can do it as follows:
1) In the main function, get the address of the first local variable:

void *stacktop;

int main(void)
{
int dummy;

stacktop = (void *)&dummy;
......

}
2)
Now, you can write

long long stackdepth(void)
{
int dummy;
long long top = (long long)stacktop;
long long bottom = (long long)&dummy;

long long result = top - bottom;
if (result < 0)
result = -result;
return result;
}

3)
Please ignore all stupid remarks like "this is not portable".
This is obviously not portable to any machine. It requires a
stack, and it supposes that an address fits in a long long.

4) Please ignore all stupid remarks like " this is undefined behavior
since you can't take the difference of two pointers that do not point to
the same object"

Have fun

jacob
Feb 21 '07 #4

P: n/a
jacob navia wrote:
so**********@gmail.com a écrit :
>>
Is there a standard function/macro/whatever you can call and determine
the distance in a C program how deep one is in the C call stack from
main.

You can do it as follows:
1) In the main function, get the address of the first local variable:

void *stacktop;

int main(void)
{
int dummy;

stacktop = (void *)&dummy;
......

}
2)
Now, you can write

long long stackdepth(void)
{
int dummy;
long long top = (long long)stacktop;
long long bottom = (long long)&dummy;

long long result = top - bottom;
if (result < 0)
result = -result;
return result;
}
0) this doesn't answer the OP's question, which was how many calls away
from main the current function is.

--
Ian Collins.
Feb 21 '07 #5

P: n/a
Ian Collins a écrit :
0) this doesn't answer the OP's question, which was how many calls away
from main the current function is.
The OP wrote "how deep one is in the C call stack". Yes, it could be
interpreted as you say, or literally, i.e. how deep is the stack.

To the original poster (OP): to know the number of procedures
stacked you have no other way than to read the debug information...
Not very easy...
Feb 21 '07 #6

P: n/a
jacob navia wrote:
Ian Collins a écrit :
>0) this doesn't answer the OP's question, which was how many calls away
from main the current function is.

The OP wrote "how deep one is in the C call stack". Yes, it could be
interpreted as you say, or literally, i.e. how deep is the stack.
To quote his example:

Something along the lines:

int main()
{
int i = stackdepth();
f2()
}

here i == 0.

void f2()
{
int i = stackdepth();
}

here i == 1

Pretty unambiguous.

--
Ian Collins.
Feb 22 '07 #7

P: n/a
Ian Collins <ia******@hotmail.comwrites:
so**********@gmail.com wrote:
>I can't see to easily find this on google or in a newsgroup

Is there a standard function/macro/whatever you can call and determine
the distance in a C program how deep one is in the C call stack from
main.
No - as some people here enjoy pointing out, there might not be a stack!
[...]

That's true, but the problem is well-defined (or at least can be
well-defined) given a decent definition for "call stack". It's a
sensible question, but the answer is "No, the language defines no way
to do that".

The closest you can come in portable code is to add an extra "depth"
parameter to every function in your program, and in every function
call pass the current value plus one. For example:

#include <stdio.h>

void foo(int data, char *stuff, int depth)
{
printf("In foo, depth is %d\n", depth);
}

void bar(double stuff, char *oreo, int depth)
{
printf("In bar, depth is %d\n", depth);
foo(42, oreo, depth + 1);
printf("Back in bar, depth is %d\n", depth);
}

int main(void)
{
bar(42.0, "blah", 1);
return 0;
}

But this is probably more effort than it's worth.

You may be able to obtain this information in a debugger, but that
doesn't give your program access to it.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Feb 22 '07 #8

P: n/a
On Feb 21, 3:21 pm, jacob navia <j...@jacob.remcomp.frwrote:
Ian Collins a écrit :
0) this doesn't answer the OP's question, which was how many calls away
from main the current function is.

The OP wrote "how deep one is in the C call stack". Yes, it could be
interpreted as you say, or literally, i.e. how deep is the stack.
It's best to read an entire message before responding. The phrase you
quoted could be misinterpreted as you did, but the entire message
couldn't.

Feb 22 '07 #9

P: n/a
jacob navia <ja***@jacob.remcomp.frwrites:
so**********@gmail.com a écrit :
>I can't see to easily find this on google or in a newsgroup
Is there a standard function/macro/whatever you can call and
determine the distance in a C program how deep one is in the C call
stack from main.
[...]
You can do it as follows:
1) In the main function, get the address of the first local variable:

void *stacktop;

int main(void)
{
int dummy;

stacktop = (void *)&dummy;
.....

}
2)
Now, you can write

long long stackdepth(void)
{
int dummy;
long long top = (long long)stacktop;
long long bottom = (long long)&dummy;

long long result = top - bottom;
if (result < 0)
result = -result;
return result;
}

3)
Please ignore all stupid remarks like "this is not portable".
This is obviously not portable to any machine. It requires a
stack, and it supposes that an address fits in a long long.

4) Please ignore all stupid remarks like " this is undefined behavior
since you can't take the difference of two pointers that do not point to
the same object"
jacob is giving you bad advice. The code assumes far more than the
existence of a stack and that an address fits in a long long. (Note
that not all pointer types are necessarily the same size, though they
commonly are.)

It assumes that the type "long long" exists; it's required in C99, but
not in C90, and some compilers will reject it in strict C90 mode.

As long as he's assuming C99, he might as well use intptr_t or
uintptr_t from <stdint.h>, which is guaranteed to be able to hold a
pointer value. If no such type exists, then the types will not be
declared, causing any program that uses it to fail compilation rather
than quietly misbehave at run time.

Converting pointers to long long and subtracting the converted results
is a silly way to compute the difference between two pointer values.
I once corrected a bug in a large piece of software that was caused by
just that kind of operation. The code failed on one of the platforms
it was required to support, because pointer representations and
pointer-to-integer conversions on that platform, though their behavior
was perfectly conforming as far as the standard is concerned, did not
match the (unnecessary) assumptions made by the original author. The
platform in question (Cray T90) is not one you're likely to run into,
but "there are more things in Heaven and Earth, Horatio ...".

You can subtract two pointers, yielding an integer result
(specifically, a result of type ptrdiff_t). If the two pointers don't
point into the same object, the subtraction invokes undefined
behavior. If you're willing to live with that, and assume that the
subtraction will behave sanely, then subtracting the pointers directly
is better than converting to integers first; the latter avoids the
undefined behavior, but can silently misbehave in some cases.

The "stupid remarks" that jacob correctly anticipated are not stupid
at all. Rather, they are legitimate warnings from people who actually
know the C language. The code he posted really isn't portable, and
comparing or subtracting pointers that don't point into the same
object really does invoke undefined behavior. You need to be aware of
these facts. Once you're aware of them, you can, if you wish, write
non-portable code that depends on assumptions beyond the requirements
of the C standard; sometimes code that works only on a limited set of
platforms is good enough.

Finally, of course, jacob's proposed solution doesn't answer your
question at all. If it works as intended (which it might on many
systems), it gives you the depth in bytes, not the number of function
calls.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Feb 22 '07 #10

P: n/a
Jacob navia wrote:
>
You can do it as follows:
2)
Now, you can write

long long stackdepth(void)
{
int dummy;
long long top = (long long)stacktop;
long long bottom = (long long)&dummy;
Ignoring the unnecessary conversion, this will give weird results on a
64 bit system if any of the pointer bit patterns represent negative long
longs.
long long result = top - bottom;
if (result < 0)
result = -result;
return result;
}
One other thing I missed the first time: this will go horribly wrong in
a threaded application where each thread uses its own stack - a classic
case of subtracting two unrelated pointers giving undefined behaviour.

--
Ian Collins.
Feb 22 '07 #11

P: n/a
You can do it as follows:
1) In the main function, get the address of the first local variable:

void *stacktop;

int main(void)
{
int dummy;

stacktop = (void *)&dummy;
.....

}

2)
Now, you can write

long long stackdepth(void)
{
int dummy;
long long top = (long long)stacktop;
long long bottom = (long long)&dummy;

long long result = top - bottom;
if (result < 0)
result = -result;
return result;

}
Why would an implementation that does use a stack need to store the
first local variable of the current function on the top of that stack?
That seems to me to be a pretty big assumption in your code that you
failed to mention to the OP. While that may be the case in your
environment there is certainly no reason that it has to be implemented
in such a way as long as I can access the variable while it is in
scope I could just as easily put it last, or anywhere else I want for
that matter.
>
3)
Please ignore all stupid remarks like "this is not portable".
This is obviously not portable to any machine. It requires a
stack, and it supposes that an address fits in a long long.
....and that long long exists
4) Please ignore all stupid remarks like " this is undefined behavior
since you can't take the difference of two pointers that do not point to
the same object"
While he is at it why doesn't he ignore stupid responses to his
question that don't even answer what he was asking. While, in some
cases, this may give you the depth in bytes (or even possibly some
other unknown unit) it does not tell him in the units he asked about
pretty unabiguously when he stated "here i == 1."
Feb 22 '07 #12

P: n/a
On Feb 22, 11:48 am, "softwared...@gmail.com" <softwared...@gmail.com>
wrote:
>
Is there a standard function/macro/whatever you can call and determine
the distance in a C program how deep one is in the C call stack from
main.
You could put:

#define ENTERING_FUNCTION() (++depth)
#define RETURN(x) do { --depth; return x; } while(0)

size_t depth = 0;

and then write all your functions like:

void func()
{
ENTERING_FUNCTION();
foo, bar;
RETURN();
}

and then inspect the 'depth' variable when you need to.
This has added benefits, eg. you could define the macros
to write a complete call trace to a log file when needed,
etc. (Obviously it has some down-sides).

Feb 22 '07 #13

P: n/a
"so**********@gmail.com" wrote:
>
I can't see to easily find this on google or in a newsgroup

Is there a standard function/macro/whatever you can call and
determine the distance in a C program how deep one is in the C
call stack from main.
Certainly, and you can do it within purely standard C.

/* main.h */
extrn int stackdepth;
/* end main.h */

/* main.c */
#includes /* as needed */
#include main.h

int stackdepth;

int main(void) {
...
stackdepth++;
functioncall(params);
stackdepth--
...
return 0;
}

Now if you use the above paradigm for all function calls, in all
modules, stackdepth will keeptrack of the nesting level. All
modules need to include main.h. Don't use longjump.

You might want to macroize the stackdepth++ and stackdepth--
operations, so you can easily eliminate them later without editing.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
Feb 22 '07 #14

This discussion thread is closed

Replies have been disabled for this discussion.