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.