Philip Potter wrote:
> Mark Bluemel wrote:
>> Philip Potter wrote:
>>> Mark Bluemel wrote:
>>>> harshal wrote:
>>>>
>>>>> but my question is that if a function can print its name with
>>>>> __FUNCTION__
>>>>> macro then why it can not print its callers name.
>>>>
>>>> The __FUNCTION__ macro is handled by the preprocessor and is
>>>> simply a textual replacement at compile time. It's not
>>>> (terribly) difficult for the preprocessor to track which
>>>> function it's processing at a time.
>>>
>>> I can't find any mention of __FUNCTION__ in n1256. I *can* find
>>> __func__. Is __FUNCTION__ at all standard?
>>
>> It doesn't matter - the point that needed to be made to the OP
>> was that macros are processed by the precompiler. The guy didn't
>> need (as far as I can see) to worry about whether the particular
>> macro he was referring to was part of the standard.
>
> Yes, that's why I replied to you and not to him. I wasn't
> nitpicking, I was asking a question, because I'm not certain
> enough of Acrobat's searching functionality to be sure that
> __FUNCTION__ isn't in there.

One more reason to use the text version of N869. There is no
__FUNCTION__. However, __func__ does exist.

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



--
Posted via a free Usenet account from http://www.teranews.com

harshal wrote:

> Hi all,
>
> Can we read the stack frame's of the current process.
> as we know that whenever a function call is made in c new functions
> stack frame

As others pointed out, it's not a good idea, it's highly system
dependent. On many systems it is possible to read the address of
the call instruction (or the one after) from the stack. In order
to get the *name* of the calling function, you'll have to compare
that address with a address map of the application. This is what
debuggers do.

> is created and pushed on to the stack. and when the function returns
> it is popped out from the stack. i want to know the caller functions
> name.

If you have full control over the source of the calling and the
called function, there is no need to mess with the stack. The
trick is to use a macro which passes __FUNCTION__ into the called
function as an argument.

>
> i mean i want something like this
>
> int a()
> {
> printf("File = %s\n",__FILE__);
> /* i want to print the callers name over here. something like this
> printf("Caller function = %s\n",__CALLER_FUN__); it should print
> b*/
> return 0;
> }

Replace with this:

#define a(...) _a(__FUNCTION__)
int _a(const char *caller)
{
printf("Caller function = %s\n",caller);
return 0;
}

Kind regards,

Iwo

Philip Potter wrote:

<...>


> Yes, that's why I replied to you and not to him. I wasn't nitpicking, I
> was asking a question, because I'm not certain enough of Acrobat's
> searching functionality to be sure that __FUNCTION__ isn't in there.

__func__ is C99, __FUNCTION__ is *not*.

--
Tor <torust [at] online [dot] no>

"I have stopped reading Stephen King novels. Now I just read C code instead"

harshal wrote:
> Hi all,
>
> Can we read the stack frame's of the current process.

This isn't an assembler programming group.

> as we know that whenever a function call is made in c new functions
> stack frame
> is created and pushed on to the stack. and when the function returns
> it is popped out from the stack.

You know more than me... the C standard says nothing about *stack* or
*frame*.


> i want to know the caller functions name.

If I needed this debug information, I would crate my own call three
tracker. First, two functions is needed:

void func_enter(const char *func_name);
void func_leave(void);

and to get the parent function, you could e.g. use a double-linked list
and call

const char *func_parent(void);

--
Tor <torust [at] online [dot] no>

"I have stopped reading Stephen King novels. Now I just read C code instead"

On Wed, 17 Oct 2007 22:33:43 -0400, in comp.lang.c , CBFalconer
<cbfalconer@yahoo.com> wrote:

>Philip Potter wrote:
>> I'm not certain
>> enough of Acrobat's searching functionality to be sure that
>> __FUNCTION__ isn't in there.
>
>One more reason to use the text version of N869.

I don't think thats an accurate comment. The text version is just as
capable of having __ FUNCTION __ as the PDF.

More of an issue is Philip's uncertainty as to how to use a search
function... :-) Hint: search for word fragments eg UNCTIO

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

On Sat, 20 Oct 2007 16:59:09 +0100, Mark McIntyre wrote:
> On Wed, 17 Oct 2007 22:33:43 -0400, in comp.lang.c , CBFalconer
> <cbfalconer@yahoo.com> wrote:
>
>>Philip Potter wrote:
>>> I'm not certain
>>> enough of Acrobat's searching functionality to be sure that
>>> __FUNCTION__ isn't in there.
>>
>>One more reason to use the text version of N869.
>
> I don't think thats an accurate comment. The text version is just as
> capable of having __ FUNCTION __ as the PDF.

The text version of N869 does not include any spacing in any of the 20
identifiers starting with __. There's no reason to assume that if one
more were mentioned, that one would.

On Sat, 20 Oct 2007 16:05:17 +0000 (UTC), in comp.lang.c , $)CHarald
van D)&k <truedfx@gmail.com> wrote:

>On Sat, 20 Oct 2007 16:59:09 +0100, Mark McIntyre wrote:
>> On Wed, 17 Oct 2007 22:33:43 -0400, in comp.lang.c , CBFalconer
>> <cbfalconer@yahoo.com> wrote:
>>
>>>Philip Potter wrote:
>>>> I'm not certain
>>>> enough of Acrobat's searching functionality to be sure that
>>>> __FUNCTION__ isn't in there.
>>>
>>>One more reason to use the text version of N869.
>>
>> I don't think thats an accurate comment. The text version is just as
>> capable of having __ FUNCTION __ as the PDF.
>
>The text version of N869 does not include any spacing in any of the 20
>identifiers starting with __. There's no reason to assume that if one
>more were mentioned, that one would.

And you know this for sure, how exactly? Other than by searching for
it, I mean. .

Chuck was in my view unreasonably claiming that the PDF was inferior
to the text version due to lack of searchability. I merely wanted to
point out that this is a false inference.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

On Sat, 20 Oct 2007 17:39:35 +0100, Mark McIntyre wrote:
> On Sat, 20 Oct 2007 16:05:17 +0000 (UTC), in comp.lang.c , $)CHarald
> van D)&k <truedfx@gmail.com> wrote:
>>The text version of N869 does not include any spacing in any of the 20
>>identifiers starting with __. There's no reason to assume that if one
>>more were mentioned, that one would.
>
> And you know this for sure, how exactly? Other than by searching for it,
> I mean. .

By also searching for any _ or __ as a separate word.