473,320 Members | 2,000 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

How can i read the stack frames of running process?

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

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;
}

int b()
{
a();
return 0;
}

int main()
{
b();
}

if there is any way please tell me.

Thanks and Regards
Harshal Shete

Oct 17 '07 #1
60 4798
On Oct 17, 3:56 pm, harshal <harshalsh...@gmail.comwrote:
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
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.

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;

}

int b()
{
a();
return 0;

}

int main()
{
b();

}

if there is any way please tell me.
You need to understand the architecture of your system, assembly,
compiler very well.
Write a logic in such a way that, you
try parsing throught the generated assembly file and get to know the
function that is calling it.
In the case of M68K there will be something like
JSR _a inside 'b' function.

Karthik Balaguru

Oct 17 '07 #2
On Oct 17, 3:56 pm, harshal <harshalsh...@gmail.comwrote:
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
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.

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;

}

int b()
{
a();
return 0;

}

int main()
{
b();

}

if there is any way please tell me.
You can write some methods based on the MAP file created by Linker and
also using the assembly listing.

Karthik Balaguru

Oct 17 '07 #3
karthikbalaguru wrote:
On Oct 17, 3:56 pm, harshal <harshalsh...@gmail.comwrote:
>Hi all,

Can we read the stack frame's of the current process.
....
You can write some methods based on the MAP file created by Linker and
also using the assembly listing.
I think it's unlikely that anyone capable of doing this would need to
post the question...
Oct 17 '07 #4
harshal wrote:
On Oct 17, 4:09 pm, r...@hoekstra-uitgeverij.nl (Richard Bos) wrote:
Can you please explain this in simple words.
OK - simple words follow:-

It is very difficult to do in any particular implementation.

It is impossible to produce a general solution.
from what you are saying it looks like it is nearly impossible.
That's about right.
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.
actually i thought of this thing because i want to resolve some memory
leak issues.
It can be a useful approach. But unless someone else has already
implemented it, it won't be at all easy...
and for that purpose i was thinking to print the callers name in
kmalloc.
I've never heard of kmalloc...
by the way i am using eCos as operating system.
Then perhaps you could ask in a newsgroup or forum related to that
operating system.
Oct 17 '07 #5
On Oct 17, 3:56 pm, harshal <harshalsh...@gmail.comwrote:
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
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.

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;

}

int b()
{
a();
return 0;

}

int main()
{
b();

}

if there is any way please tell me.
You can try something as below :
( This is just a rough idea for you . )

You need to know the register that has the address of the current
frame info.
and that address is normally saved to the frame by the called
function.

Create a LIFO list with this info
a) address of the calling function frame
b) return address
c) parameter list

Every function call should add a frame to the list.
Every return from function will delete the frame.

So, if you know the register that has the address of the current frame
info and the
value at that register, then you can make it up on your own.

Also , Many ways are dependent on parsing through the assembly files
and MAP files .

Karthik Balaguru

Oct 17 '07 #6
On Oct 17, 3:56 pm, harshal <harshalsh...@gmail.comwrote:
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
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.

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;

}

int b()
{
a();
return 0;

}

int main()
{
b();

}

if there is any way please tell me.


You can try something as below :
( This is just a rough idea for you . )

You need to know the system architecture very well for this.

You need to know the register that has the address of the current
frame info.
and that address is normally saved to the frame by the called
function.

Create a LIFO list with info something as below such as for Every
function call that will add a frame to the list.
and for every return from function, it will delete the frame.
a) address of the calling function frame
b) return address
c) parameter list

So, if you know the register that has the address of the current frame
info and the
value at that register, then you can make it up on your own.

Also , Many ways are dependent on parsing through the assembly files
and MAP files .

Karthik Balaguru

Oct 17 '07 #7

"Richard Bos" <rl*@hoekstra-uitgeverij.nlwrote in message
news:47****************@news.xs4all.nl...
harshal <ha**********@gmail.comwrote:
>Can we read the stack frame's of the current process.

In reliable ISO C, you don't even know that you have something called a
"current process"[1], nor a "stack frame", let alone anything that is in
this stack frame's possession. All these details are system-specific,
all functions to read them are necessarily also system-specific, and in
all probability, old systems make doing so a brittle, unreliable process
while more modern systems (wisely) forbid you to put your grubby mitts
inside the running program's data without pre-arranged permission.
now, this is curious:
I personally do not know of any arch requiring "pre-arranged permission to
put one's grubby mitts in the program's data".

there are a lot of things generally prevented by the OS and hardware, but I
have not heard of this one...
unless of course, by 'pre-arranged permission' you mean 'have to write stuff
in assembler...'.
well, this is true. now, the fun part, is getting the name for the
address...

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

You may think you know that; I think you merely suspect it.
yes, plausible. there is little requiring C compilers, for example, to not
perform inlining, tail-call optimization, and other such tricks...

>i want to know the caller functions name.

Pass it. Don't rely on dangerous, unportable, and dirty hackery.
unless you want to be like me and write your own dynamic compiler framework,
where one comes face to face with this kind of ugly and unportable
hackerry...
now, it is the case, that there is probably no simple answer here either, as
nearly any attempt at an answer would likely also require that the reader
understand what all is going on here.

Oct 17 '07 #8
On Oct 17, 3:56 pm, harshal <harshalsh...@gmail.comwrote:
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
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.

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;

}

int b()
{
a();
return 0;

}

int main()
{
b();

}

if there is any way please tell me.
kmalloc comes from linux. I think, gdb has good provisions w.r.t stack
frame .
There are many ways to print information about the selected stack
frame using gdb.

Karthik Balaguru

Oct 17 '07 #9
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?

--
Philip Potter pgp <atdoc.ic.ac.uk
Oct 17 '07 #10
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.
Oct 17 '07 #11
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.

--
Philip Potter pgp <atdoc.ic.ac.uk
Oct 17 '07 #12
Philip Potter wrote:
Mark Bluemel wrote:
>Philip Potter wrote:
>>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.
I'm fairly sure this was discussed sometime ago. __FUNCTION__ is a
gcc-specific macro, I thought...

A quick google finds for example -
http://groups.google.co.uk/group/com...abb500fc06fcb3

That's put me right... Neither __FUNCTION__ or __func__ are, strictly
speaking, macros...
Oct 17 '07 #13

"Philip Potter" <pg*@see.sig.invalidschrieb im Newsbeitrag
news:ff**********@aioe.org...
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.
__func__ is not a marco

The identifier __func_ _ shall be implicitly declared by the translator as
if,

immediately following the opening brace of each function definition, the
declaration

static const char _ _func_ _[] = "function-name";

appeared, where function-name is the name of the lexically-enclosing
function.61)

Bye, Jojo
Oct 17 '07 #14
harshal <ha**********@gmail.comwrites:
and for that purpose i was thinking to print the callers name in
kmalloc.
Just insert a call dump_stack(); you'll get everything.

Chip

--
Charles M. "Chip" Coldwell
"Turn on, log in, tune out"
Somerville, Massachusetts, New England
Oct 17 '07 #15
On Oct 17, 2:15 pm, karthikbalaguru <karthikbalagur...@gmail.com>
wrote:
On Oct 17, 3:56 pm, harshal <harshalsh...@gmail.comwrote:
Can we read the stack frame's of the current process.

kmalloc comes from linux.
Nonsense. It no more comes from Linux than from eCos.

Oct 17 '07 #16
On Oct 17, 3:56 pm, harshal <harshalsh...@gmail.comwrote:
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
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.
It can be done, but you need to understand your complete system
architecture properly.
What is the architecture you are working on ?

You can also do that by parsing the assembly code generated by your
compiler for that program.
For example in your case, w.r.t M68K family, you need to find the
location for the presence of the following which would give you the
answer as function 'b'.
JSR _a

Karthik Balaguru
Karthik Balaguru

Oct 17 '07 #17
Mark Bluemel <ma**********@pobox.comwrites:
[...]
That's put me right... Neither __FUNCTION__ or __func__ are, strictly
speaking, macros...
Correct.

__FUNCTION__ is non-standard, but is provided by gcc as an extension.
In older versions of gcc, it's a "magic identifier" which is replaced
by a string literal; it could concatenated as if it were a literal,
but it didn't work with #ifdef. In newer versions of gcc, it's simply
another name for __func__.

__func__ is standard in C99, but didn't exist in C90 (though of course
a C90 compiler could provide it as an extension). It acts as if it
were declared as a static const char[] immediately following the
opening brace of the function definition.

If you think about it, __FUNCTION__ or __func__ can't be a macro,
since the preprocessor (more precisely, translation phase 4, which
handles macro expansion) runs before function definitions have been
processed.

--
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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Oct 17 '07 #18
Chip Coldwell <co******@gmail.invalidwrites:
harshal <ha**********@gmail.comwrites:
>and for that purpose i was thinking to print the callers name in
kmalloc.

Just insert a call dump_stack(); you'll get everything.
Presumably implementing dump_stack() is left as an exercise. (There's
no such function in standard C, and there's no portable way of
implementing it; for a given implementation, there may not even be a
non-portable way of implementing 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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Oct 17 '07 #19
karthikbalaguru wrote:
>
.... snip ...
>
kmalloc comes from linux. I think, gdb has good provisions w.r.t
stack frame . There are many ways to print information about the
selected stack frame using gdb.
The subject of this newsgroup is the C language, as specified in
the various (current and past) C standards. None of kmalloc,
linux, gdb, stack frame, have ever appeared or been specified in
any C standard, and are all off-topic and system dependent here.
Note the 'system dependent'. That means such discussions are not
general to all C systems, and thus are not suitable for this
newsgroup.

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

Oct 19 '07 #20
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

Oct 19 '07 #21
karthikbalaguru wrote:
>
.... snip ...
>
You can write some methods based on the MAP file created by Linker
and also using the assembly listing.
Please tell us exactly where the C standard discusses the MAP file,
or the action of the Linker. Also where it discusses 'the assembly
listing'.

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

Oct 19 '07 #22
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"
Oct 19 '07 #23
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"
Oct 19 '07 #24
On Wed, 17 Oct 2007 22:33:43 -0400, in comp.lang.c , CBFalconer
<cb********@yahoo.comwrote:
>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
Oct 20 '07 #25
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
<cb********@yahoo.comwrote:
>>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.
Oct 20 '07 #26
On Sat, 20 Oct 2007 16:05:17 +0000 (UTC), in comp.lang.c , $)CHarald
van D)&k <tr*****@gmail.comwrote:
>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
<cb********@yahoo.comwrote:
>>>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
Oct 20 '07 #27
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 <tr*****@gmail.comwrote:
>>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.
Oct 20 '07 #28
On Sat, 20 Oct 2007 17:17:46 +0000 (UTC), in comp.lang.c , $)CHarald
van D)&k <tr*****@gmail.comwrote:
>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 <tr*****@gmail.comwrote:
>>>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.
I'm wondering which part of my last sentence was tricky to
understand.... :-)

--
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
Oct 20 '07 #29
On Sat, 20 Oct 2007 18:54:58 +0100, Mark McIntyre wrote:
On Sat, 20 Oct 2007 17:17:46 +0000 (UTC), in comp.lang.c , $)CHarald
van D)&k <tr*****@gmail.comwrote:
>>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 <tr*****@gmail.comwrote:
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.

I'm wondering which part of my last sentence was tricky to
understand.... :-)
Well, what did you mean by "it" ? I was assuming your point was that
searching for "__func__" won't show you whether the text file also
contains "_ _func_ _" in other places. If your point was merely that it
is possible for a plain text file to contain "_ _func_ _", then you're
correct, of course, but I don't see why it matters once you know that
this one doesn't.
Oct 20 '07 #30
On Sat, 20 Oct 2007 18:06:09 +0000 (UTC), in comp.lang.c , $)CHarald
van D)&k <tr*****@gmail.comwrote:
>On Sat, 20 Oct 2007 18:54:58 +0100, Mark McIntyre wrote:
>On Sat, 20 Oct 2007 17:17:46 +0000 (UTC), in comp.lang.c , $)CHarald
van D)&k <tr*****@gmail.comwrote:
>>>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 <tr*****@gmail.comwrote:
>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.

I'm wondering which part of my last sentence was tricky to
understand.... :-)

Well, what did you mean by "it" ?
*sigh*.

Its irrelevant what "it" is. Either the plaintext or the PDF can be
handily searched for whatever you want to. Obviously if there are
typos (I recall some bizarre diacritical being used occasionally, and
definitely some spaces where none should be), it makes searches harder
but this is not the fault of the file format. There is no intrinsic
reason (other than ludditism) to distrust either search facility.

--
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
Oct 20 '07 #31
On Sat, 20 Oct 2007 22:50:19 +0100, Mark McIntyre wrote:
Either the plaintext or the PDF can be
handily searched for whatever you want to. Obviously if there are typos
(I recall some bizarre diacritical being used occasionally, and
definitely some spaces where none should be), it makes searches harder
but this is not the fault of the file format. There is no intrinsic
reason (other than ludditism) to distrust either search facility.
It doesn't have to be an intrinsic reason. The text version of n869 could
have contained spellings that cause problems for searching, but doesn't.
The PDF versions of standards' drafts do. What alternatives the formats
allow is irrelevant.

Let's go upthread and find the message you had a problem with:

[CBFalconer wrote:]
[Joachim Schmitz 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.

One more reason to use the text version of N869. There is no
__FUNCTION__. However, __func__ does exist.
There is no claim that it is an inherent property of text files that they
will contain correct spellings. The text version of n869 happens to be
one that does contain correct spellings -- please don't start with "how
do you know?" again -- and for that reason searching it in produces
better results.
Oct 21 '07 #32
Harald van D©¦k <tr*****@gmail.comwrites:
[...]
Let's go upthread and find the message you had a problem with:

[CBFalconer wrote:]
>[Joachim Schmitz 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.

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

There is no claim that it is an inherent property of text files that they
will contain correct spellings. The text version of n869 happens to be
one that does contain correct spellings -- please don't start with "how
do you know?" again -- and for that reason searching it in produces
better results.
As far as I can tell, it has not yet been established that, for
example, n1256.pdf contains any incorrect spellings.

--
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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Oct 21 '07 #33
On Sun, 21 Oct 2007 01:51:36 -0700, Keith Thompson wrote:
As far as I can tell, it has not yet been established that, for example,
n1256.pdf contains any incorrect spellings.
From n869.txt, from the foreword:
-- __func__ predefined identifier

From n1256.pdf:
ā€” _ _func_ _ predeļ¬ned identiļ¬er
Oct 21 '07 #34
In article <11**********************@q5g2000prf.googlegroups. com>,
harshal <ha**********@gmail.comwrites
>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
is created and pushed on to the stack.
No, this is not always the case. It only happens on stack based systems.
Also some compilers don't use a stack even when the MCU does.

It will depend very much on the target MCU and the compiler used neither
of which you mentioned.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Oct 21 '07 #35
Keith Thompson said:

<snip>
As far as I can tell, it has not yet been established that, for
example, n1256.pdf contains any incorrect spellings.
Apart from "Septermber", of course.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Oct 21 '07 #36
Mark McIntyre wrote:
Either the plaintext or the PDF can be handily searched for whatever
you want to. Obviously if there are typos (I recall some bizarre
diacritical being used occasionally, and definitely some spaces where
none should be), it makes searches harder but this is not the fault of
the file format. There is no intrinsic reason (other than ludditism)
to distrust either search facility.
It's not clear to me what you mean by "instrinsic" here.

I have a couple of reasons for distrusting the search facility for PDFs
in Adobe Acrobat. On general principle, it's much easier to screw up
the programming of a search facility for a complex format, and it's also
more likely that a richer encoding will contain more errors merely by
chance. But more specifically, I have several times seen a PDF search
fail for items that I can actually see. There are any number of reasons
this can happen with PDF, none of which apply to plain text.

- Ernie http://home.comcast.net/~erniew
Oct 21 '07 #37
Ernie Wright <er****@comcast.netwrites:
Mark McIntyre wrote:
>Either the plaintext or the PDF can be handily searched for whatever
you want to. Obviously if there are typos (I recall some bizarre
diacritical being used occasionally, and definitely some spaces where
none should be), it makes searches harder but this is not the fault of
the file format. There is no intrinsic reason (other than ludditism)
to distrust either search facility.

It's not clear to me what you mean by "instrinsic" here.

I have a couple of reasons for distrusting the search facility for PDFs
in Adobe Acrobat. On general principle, it's much easier to screw up
the programming of a search facility for a complex format, and it's also
more likely that a richer encoding will contain more errors merely by
More spelling errors? How do you figure that out? Or are you saying the
same thing twice? ie its harder to program a search algorithm for more
complex formats? Which is as obvious as water is wetter than dry sand.
chance. But more specifically, I have several times seen a PDF search
fail for items that I can actually see. There are any number of reasons
this can happen with PDF, none of which apply to plain text.
There is one reason : that the search algorithm is full of errors. I
have never personally had a PDF search not work.
>
- Ernie http://home.comcast.net/~erniew
Oct 21 '07 #38
Harald van D©¦k <tr*****@gmail.comwrites:
On Sun, 21 Oct 2007 01:51:36 -0700, Keith Thompson wrote:
>As far as I can tell, it has not yet been established that, for example,
n1256.pdf contains any incorrect spellings.

From n869.txt, from the foreword:
-- __func__ predefined identifier

From n1256.pdf:
ā€” _ _func_ _ predeļ¬ned identiļ¬er
Get a better PDF reader. I get:

? __func_ _ predefined identifier

(using Adobe Reader 8.1.0 under Windows XP).

The splitting of the underscores is still annoying (probably the space
is necessary because without it each pair would be difficult to
distinguish from a single underscore), but at least it gets the
ligatures right.

Your basic point is correct, though I still find the PDF quite
convenient.

--
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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Oct 21 '07 #39
On Sun, 21 Oct 2007 08:13:50 +0000 (UTC), in comp.lang.c , $)CHarald
van D)&k <tr*****@gmail.comwrote:
>The text version of n869 could
have contained spellings that cause problems for searching, but doesn't.
You assert.
>The PDF versions of standards' drafts do.
You assert.
>What alternatives the formats allow is irrelevant.
The complaint was that the pdf is harder to search.....
>Let's go upthread and find the message you had a problem with:

[CBFalconer wrote:]
>[Joachim Schmitz 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.
Correct - CBF is suggesting that because someone have difficulties
operating the search function in Acrobat, they should switch to
using plaintext version.
>There is no claim that it is an inherent property of text files that they
will contain correct spellings.
You're at a disadvantage as you're evidently unaware of the history of
this debate.
>please don't start with "how do you know?" again --
Well, how do you?
>and for that reason searching it in produces
better results.
In your opinion, based on your limited experience.
--
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
Oct 21 '07 #40
On Sun, 21 Oct 2007 11:00:37 -0400, in comp.lang.c , Ernie Wright
<er****@comcast.netwrote:
>Mark McIntyre wrote:
>Either the plaintext or the PDF can be handily searched for whatever
you want to. Obviously if there are typos (I recall some bizarre
diacritical being used occasionally, and definitely some spaces where
none should be), it makes searches harder but this is not the fault of
the file format. There is no intrinsic reason (other than ludditism)
to distrust either search facility.

It's not clear to me what you mean by "instrinsic" here.
intrinsic as in built in?
>I have a couple of reasons for distrusting the search facility for PDFs
in Adobe Acrobat. On general principle, it's much easier to screw up
the programming of a search facility for a complex format,
This falls under the heading of "ludditism"... :-)
and it's also
more likely that a richer encoding will contain more errors merely by
chance.
AFAIK the plaintext is generated _from_ the PDF. I doubt its proofread
afterwards, either.
>But more specifically, I have several times seen a PDF search
fail for items that I can actually see. There are any number of reasons
this can happen with PDF, none of which apply to plain text.
While there are different reasons why the plaintext search might fail.
--
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
Oct 21 '07 #41
On Sun, 21 Oct 2007 11:22:49 -0700, Keith Thompson wrote:
Harald van Dijk <tr*****@gmail.comwrites:
>On Sun, 21 Oct 2007 01:51:36 -0700, Keith Thompson wrote:
>>As far as I can tell, it has not yet been established that, for
example, n1256.pdf contains any incorrect spellings.

From n869.txt, from the foreword:
-- __func__ predefined identifier

From n1256.pdf:
ā€” _ _func_ _ predeļ¬ned identiļ¬er

Get a better PDF reader. I get:

? __func_ _ predefined identifier

(using Adobe Reader 8.1.0 under Windows XP).

The splitting of the underscores is still annoying (probably the space
is necessary because without it each pair would be difficult to
distinguish from a single underscore), but at least it gets the
ligatures right.
The problem with the spellings in this thread was that you can't search
for __func__ and find where it's referenced. (Or more accurately, that
you can't search for __FUNCTION__ to find that it's not referenced.) It's
good that your PDF reader can tell that the leading __ should not include
a space, and I'll try some alternative readers myself, but unless one can
also tell for the trailing __, I doubt searching would start working.
Your basic point is correct, though I still find the PDF quite
convenient.
So do I.
Oct 22 '07 #42
On Sun, 21 Oct 2007 23:44:24 +0100, Mark McIntyre wrote:
On Sun, 21 Oct 2007 08:13:50 +0000 (UTC), in comp.lang.c , $)CHarald
van D)&k <tr*****@gmail.comwrote:
>>The text version of n869 could
have contained spellings that cause problems for searching, but doesn't.

You assert.
I have verified, but you conveniently chose to ignore this repeatedly.
>>The PDF versions of standards' drafts do.

You assert.
I have verified, but you conveniently chose to ignore this repeatedly.

I'm done here.
Oct 22 '07 #43
$)CHarald van D)&k wrote:
Keith Thompson wrote:
>As far as I can tell, it has not yet been established that, for
example, n1256.pdf contains any incorrect spellings.

From n869.txt, from the foreword:
-- __func__ predefined identifier

From n1256.pdf:
ā€” _ _func_ _ predeļ¬ned identiļ¬er
The blanks between '_' chars are an effect of the font used. The
other anomaly is due to the use of some peculiar character to
represent the sequence 'fi'. So there are no incorrect spelling
identified, but one more of the penalties of .PDF publication is
exposed.

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

Oct 22 '07 #44
Mark McIntyre wrote:
Harald van D)&k <tr*****@gmail.comwrote:
>Mark McIntyre wrote:
>>CBFalconer <cb********@yahoo.comwrote:
.... snip ...
>>>>
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.
No, you misinterpret my comment. The point is that PDF searches
can only be done by a PDF reader. With text you have a choice,
such as grep, a text editor, or any other piece of text handling
software on your system. So you can suit your search methods to
software familiar to you.

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

Oct 22 '07 #45
Keith Thompson <ks***@mib.orgwrites:
I get:

? __func_ _ predefined identifier

(using Adobe Reader 8.1.0 under Windows XP).

The splitting of the underscores is still annoying (probably the space
is necessary because without it each pair would be difficult to
distinguish from a single underscore), but at least it gets the
ligatures right.
I refer to the Standard so often that, many years ago, I did a
one-time conversion of my PDF to plain text, and then as I've
referred to it over the years I've fixed up the more annoying
problems with the conversion. So it may not be possible to get a
perfect text rendering right away, but it gets better over time.
--
Ben Pfaff
http://benpfaff.org
Oct 22 '07 #46
Mark McIntyre wrote:
On Sun, 21 Oct 2007 11:00:37 -0400, in comp.lang.c , Ernie Wright
<er****@comcast.netwrote:
>>Mark McIntyre wrote:
>>There is no intrinsic reason (other than ludditism) to distrust
either search facility.

It's not clear to me what you mean by "instrinsic" here.

intrinsic as in built in?
Well, yeah, but as opposed to what? I couldn't tell if I disagreed with
you or not--whether the reasons I offered were ones you characterize as
instrinsic.
>>I have a couple of reasons for distrusting the search facility for PDFs
in Adobe Acrobat. On general principle, it's much easier to screw up
the programming of a search facility for a complex format,

This falls under the heading of "ludditism"... :-)
Or Luddism, even. You say that like it's a bad thing.
>and it's also more likely that a richer encoding will contain more
errors merely by chance.

AFAIK the plaintext is generated _from_ the PDF. I doubt its proofread
afterwards, either.
Wait, I thought we were talking about the general case. If we're
talking solely about ISO C drafts, we don't have to guess about which
ones are better for searching. That's testable.
>But more specifically, I have several times seen a PDF search fail
for items that I can actually see. There are any number of reasons
this can happen with PDF, none of which apply to plain text.

While there are different reasons why the plaintext search might fail.
There's no symmetry here. There are *more* reasons that a PDF search
might fail. What, for example, do you think is going on in this search:

http://home.comcast.net/~erniew/images/pdfsearch.gif

- Ernie http://home.comcast.net/~erniew
Oct 22 '07 #47
Richard wrote:
Ernie Wright <er****@comcast.netwrites:
>>I have a couple of reasons for distrusting the search facility for PDFs
in Adobe Acrobat. On general principle, it's much easier to screw up
the programming of a search facility for a complex format, and it's also
more likely that a richer encoding will contain more errors merely by

More spelling errors?
No.
Or are you saying the same thing twice? ie its harder to program a
search algorithm for more complex formats? Which is as obvious as
water is wetter than dry sand.
Evidently it's *not* that obvious.
>>chance. But more specifically, I have several times seen a PDF search
fail for items that I can actually see. There are any number of reasons
this can happen with PDF, none of which apply to plain text.

There is one reason : that the search algorithm is full of errors.
Are you saying that's the only possible reason? There are many others.

Or are you saying that this is one reason that applies to both PDF and
plain text? Clearly there is more than one of those also. I was
specifically talking about reasons that apply to PDF and do not apply
to plain text.
I have never personally had a PDF search not work.
I have.

http://home.comcast.net/~erniew/images/pdfsearch.gif

- Ernie http://home.comcast.net/~erniew
Oct 22 '07 #48
On Sat, 20 Oct 2007 18:09:04 -0400, in comp.lang.c , CBFalconer
<cb********@yahoo.comwrote:
>No, you misinterpret my comment. The point is that PDF searches
can only be done by a PDF reader. With text you have a choice,
such as grep, a text editor, or any other piece of text handling
software on your system.
Right - so whereas a PDF can only be searched by tool which can read
PDFs, a text file can only be searched by a tool which can read
text*.... hmm.
>So you can suit your search methods to software familiar to you.
Why would anyone under the age of 30 be familiar with arcane stuff
like grep? I find it hard to find anyone under that age who even knows
that computers _have_ a commandline, and for GUI users,
double-clicking a file of any sort merely starts the default viewer
with whatever search facilities there are.
(* okay, I grant you, you could use a disk editor to search a text
file - probably, if it was 7-bit ascii, and stored in sequential
bytes...)
--
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
Oct 22 '07 #49
On Mon, 22 Oct 2007 05:40:01 +0000 (UTC), in comp.lang.c , Harald van
D)&k <tr*****@gmail.comwrote:
>On Sun, 21 Oct 2007 23:44:24 +0100, Mark McIntyre wrote:
>On Sun, 21 Oct 2007 08:13:50 +0000 (UTC), in comp.lang.c , $)CHarald
van D)&k <tr*****@gmail.comwrote:
>>>The text version of n869 could
have contained spellings that cause problems for searching, but doesn't.

You assert.

I have verified, but you conveniently chose to ignore this repeatedly.
Not at all. My point is, unless you choose to abandon all reason you
must accept your claim is unprovable except by me doing my own search
or by you publishing some evidence that there are no spelling errors
in the file. I'm not sure how you could usefully do that.

You could I suppose load it into a spell checker, and carefully train
it to ignore all the specialist language, diacriticals, punctuation
marks etc etc etc. You'd need to get someone to double-check your
results, to remove any possibility of you making a minor mistake, or
overlooking an error.

So I'm betting that what you mean is "I have yet to detect any
spelling errors in hte plaintext version" - which is fair enough, but
not the same as "there are no errors, period".

Meanwhile since i've used the PDF extensively with no issues
searching, I must disconcur with your findings regarding that.
--
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
Oct 22 '07 #50

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

15
by: Andrew | last post by:
Last night I was reading about implementing my own stack. The example given pushes items on and off the stack at the start and end of each procedure (ie. in a std module). What's not so clear is...
1
by: garth ferris | last post by:
i'm having a problem with a 3d engine i'm writing (just for fun, i'm kind of a beginner) and i was wondering if anyone could look through the following drwtsn32.log entry. the problem (among...
5
by: Adrian | last post by:
Is there a way (understandably non-portable) to get the call stack from within a function? That is, assuming the application has been compiled with symbols, get the list of calling function names...
2
by: rrossney | last post by:
Please look at the "what I've already done" section of this message before responding to it: I believe that I've done everything that the people who experience this error are typically told to do....
24
by: arcticool | last post by:
I had an interview today and I got destroyed :( The question was why have a stack and a heap? I could answer all the practical stuff like value types live on the stack, enums are on the stack, as...
4
by: code break | last post by:
Hi all, What is the difference between stack pointer and frame pointer ? Any suggestions are welcome ,,,
20
by: deepak | last post by:
Hi All, In C I heard the stack grows from top to bottom and heap from bottom to top. Is it compiler depend?
87
by: CJ | last post by:
Hello: We know that C programs are often vulnerable to buffer overflows which overwrite the stack. But my question is: Why does C insist on storing local variables on the stack in the first...
1
by: davidcollins001 | last post by:
Hi, I am trying to write a stack walking program to trace back along the stack for a process that the trace function is called from. I am doing it the cheating way, in that I have a ruby program...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
0
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.