stack

H

Harald van Dijk

On this newsgroup, there are no non-standard compliant ways to do
anything. Anything of that nature is off=topic,

Please don't use topicality as an excuse or defence for lies. I don't know
if MisterE is aware of the existence of any non-portable methods of
accessing a function call's return address, but you are.
 
R

Richard

CBFalconer said:
On this newsgroup, there are no non-standard compliant ways to do
anything. Anything of that nature is off=topic, and may be found
on specialized news-groups dealing with the authors system.

Dont be such a prissy twit. If people want help in a C related area and
it happens that someone here can help it would be ludicrous not to.
 
K

Keith Thompson

CBFalconer said:
On this newsgroup, there are no non-standard compliant ways to do
anything. Anything of that nature is off=topic, and may be found
on specialized news-groups dealing with the authors system.

The question was "Is it possible to access this value..??" (namely the
return address for a function). Either "Yes, but it's
system-specific", or "There's no portable way to do it" would be a
correct answer (though the latter is incomplete).

An unqualified "No." is not a correct answer.

People who post off-topic questions should not be punished by being
fed false information. And for that matter, the question itself
wasn't off-topic, though a detailed answer without a redirection would
have been.
 
W

Walter Roberson

Keith Thompson said:
The question was "Is it possible to access this value..??" (namely the
return address for a function). Either "Yes, but it's
system-specific", or "There's no portable way to do it" would be a
correct answer (though the latter is incomplete).

"Yes, but it's system-specific" is incorrect. On some systems
there is no mechanism to get at the return address.
"There's no portable way to do it" is correct, as it includes
the case of there being no way to do it on some systems.
 
C

CBFalconer

Keith said:
.... snip ...

.... snip ...

People who post off-topic questions should not be punished by
being fed false information. And for that matter, the question
itself wasn't off-topic, though a detailed answer without a
redirection would have been.

I don't think I did 'punish'. I told him where to go, in general
terms. He didn't specify his system.
 
N

Nick Keighley

Harold said:
Is it possible to access [the return address] value..??
No.
Of course it is. The OP did not request a standard compliant way to do
it after all
On this newsgroup, there are no non-standard compliant ways to do
anything. Anything of that nature is off=topic,

Please don't use topicality as an excuse or defence for lies.

its not a lie. It's a fact. Your statement is incorrect. There
*is* no standard way to do this and since the topic of this NG
is standard C there is no way to do it that is topical to this
NG. Though I must admit I'd have suggested trying another NG.
I don't know
if MisterE is aware of the existence of any non-portable methods of
accessing a function call's return address, but you are.


--
Nick Keighley

"computers are no longer intended for those who can
understand mathematics, but only for those who cannot."
Herman Rubin (comp.lang.c)
 
N

Nick Keighley

jt wrote:


In a machine that can execute the standard C language, there is no
need for a stack. This makes it hard to access a return address
(of unknown form) stored in a non-existant stack.

but the information must be stored *somewhere* otherwise
the implementation wouldn't be able to return from the function.
Admittedly the implementaion is under no obligation to make
it available to the user.


--
Nick Keighley

This is not the same as a proof of correctness,
but proofs of correctness can only be constructed by computer
scientists with fancy degrees, not by mere clever programmers.
Ben Pfaff
 
C

Chris Dollin

Nick said:
but the information must be stored *somewhere* otherwise
the implementation wouldn't be able to return from the function.
Admittedly the implementaion is under no obligation to make
it available to the user.

In the program above, if the compiler chose to inline `fun`, the
"return address" would be "stored" by the implicit fall-through of
one instruction to the next [1].

As we have discussed before, not all C programs need an explicit
run-time stack data-structure. Of those that do, that structure
need not correspond to the local hardware's notion of "stack",
if it has one. Even if it does, the implementation is under no
requirement of the C standard to expose that stack to C programs.

And even if it /does/, mere ability should not elicit reckless
employment. One can, after all, clean one's teeth with a
screwdriver.

[1] On an implementation that uses "instructions", of course.
 
S

santosh

Nick said:
but the information must be stored *somewhere* otherwise
the implementation wouldn't be able to return from the function.

And it must also *behave* like a LIFO data structure. So at least a
software based stack is necessary.
 
S

santosh

Chris said:
Nick said:
but the information must be stored *somewhere* otherwise
the implementation wouldn't be able to return from the function.
Admittedly the implementaion is under no obligation to make
it available to the user.

In the program above, if the compiler chose to inline `fun`, the
"return address" would be "stored" by the implicit fall-through of
one instruction to the next [1].

As we have discussed before, not all C programs need an explicit
run-time stack data-structure.

At least programs making use of recursion do, as far as I can see, and I
doubt that any sane implementation is going to use different strategies
for both these cases.
Of those that do, that structure
need not correspond to the local hardware's notion of "stack",
if it has one. Even if it does, the implementation is under no
requirement of the C standard to expose that stack to C programs.

And even if it /does/, mere ability should not elicit reckless
employment. One can, after all, clean one's teeth with a
screwdriver.

[1] On an implementation that uses "instructions", of course.
 
H

Harold Aptroot

Nick Keighley said:
Harold Aptroot wrote:
Is it possible to access [the return address] value..??

Of course it is. The OP did not request a standard compliant way to
do
it after all
On this newsgroup, there are no non-standard compliant ways to do
anything. Anything of that nature is off=topic,

Please don't use topicality as an excuse or defence for lies.

its not a lie. It's a fact. Your statement is incorrect. There
*is* no standard way to do this and since the topic of this NG
is standard C there is no way to do it that is topical to this
NG. Though I must admit I'd have suggested trying another NG.

So suppose someone asks here how to make coffee, we just tell him it's
completely impossible because the C standard has nothing to say on it?
 
B

Bartc

jt said:
hello everyone..

int fun()
{
/* anything */
}
int main(void)
{
fun();
}

in this program, when the control is transferred to function fun()..
the return address is pushed to the stack..
Is it possible to access this value..??

No problem, I thought, with a few lines of asm. But when I actually tried
it, it was quite difficult to pick up the return address.

On my machine, it depends on how many bytes of local variables there are in
a function. So this would require compiler help, or you have to tailor the
asm code to each function, and have it break as soon you change any
variables.

So whatever it is you're trying to do, best to think of a different way...
 
S

santosh

Harold said:
news:[email protected]...
"MisterE" <[email protected]> wrote in message
Is it possible to access [the return address] value..??

No.

Of course it is. The OP did not request a standard compliant way
to do
it after all

On this newsgroup, there are no non-standard compliant ways to do
anything. Anything of that nature is off=topic,

Please don't use topicality as an excuse or defence for lies.

its not a lie. It's a fact. Your statement is incorrect. There
*is* no standard way to do this and since the topic of this NG
is standard C there is no way to do it that is topical to this
NG. Though I must admit I'd have suggested trying another NG.

So suppose someone asks here how to make coffee, we just tell him it's
completely impossible because the C standard has nothing to say on it?

No. We tell him that it's not possible to make coffee using *only*
Standard C, that system specific extensions will be necessary, and to
ask for more information in a group which deals with the system or
implementation the poster is using.
 
S

santosh

Bartc said:
news:[email protected]...

No problem, I thought, with a few lines of asm. But when I actually
tried it, it was quite difficult to pick up the return address.

On my machine, it depends on how many bytes of local variables there
are in a function. So this would require compiler help, or you have to
tailor the asm code to each function, and have it break as soon you
change any variables.

So whatever it is you're trying to do, best to think of a different
way...

I strongly suspect that all the compilers that the OP is likely to care
about provide a built-in for this purpose.
 
H

Harold Aptroot

santosh said:
Harold said:
news:[email protected]...
Is it possible to access [the return address] value..??

No.

Of course it is. The OP did not request a standard compliant way
to do
it after all

On this newsgroup, there are no non-standard compliant ways to do
anything. Anything of that nature is off=topic,

Please don't use topicality as an excuse or defence for lies.

its not a lie. It's a fact. Your statement is incorrect. There
*is* no standard way to do this and since the topic of this NG
is standard C there is no way to do it that is topical to this
NG. Though I must admit I'd have suggested trying another NG.

So suppose someone asks here how to make coffee, we just tell him it's
completely impossible because the C standard has nothing to say on it?

No. We tell him that it's not possible to make coffee using *only*
Standard C, that system specific extensions will be necessary, and to
ask for more information in a group which deals with the system or
implementation the poster is using.

See? Now that's different than MisterE's plain "no"
 
S

santosh

Harold said:
santosh said:
Harold said:
Is it possible to access [the return address] value..??

No.
So suppose someone asks here how to make coffee, we just tell him
it's completely impossible because the C standard has nothing to say
on it?

No. We tell him that it's not possible to make coffee using *only*
Standard C, that system specific extensions will be necessary, and to
ask for more information in a group which deals with the system or
implementation the poster is using.

See? Now that's different than MisterE's plain "no"

If "MisterE" meant his "No" as specifically within the context of ISO C,
then he is factually correct, though a more verbose, explanatory
response would've perhaps been better, but many such responses were
already provided to the OP by the time MisterE's post showed up on my
newsserver.
 
C

Chris Dollin

santosh said:
Chris Dollin wrote:

At least programs making use of recursion do, as far as I can see,

Not all programs that make use of recursion need an explicit run-time
stack, either. But yes, programs (or parts thereof) that do non-tail
recursion will need /something/ like a run-time stack.
and I
doubt that any sane implementation is going to use different strategies
for both these cases.

Whole-program compilation might well choose to, if that was more
efficient. Suppose one were making a serious attempt to compile
as-Standard-as-possible C programs for the 6502, where stack depth
/really/ matters. Or the PDP8, which has the added delightful
feature that the subroutine return address gets planted /at the
target of the call instruction/.

I don't know if today's embedded processors are equally jabberwock-laden,
(except that the ARM isn't), but I'd lay odds that on at least some of
them, if essential recursion is allowed at all, the compiler will
treat recursive (or re-entrant) functions differently from non-R
functions.
 
C

Chris Dollin

Chris said:
I don't know if today's embedded processors are equally jabberwock-laden,
(except that the ARM isn't), but I'd lay odds that on at least some of
them, if essential recursion is allowed at all, the compiler will
treat recursive (or re-entrant) functions differently from non-R
functions.

For "will treat" safer to read "will treat, or can be told to treat".
 
H

Harold Aptroot

CBFalconer said:
On this newsgroup, there are no non-standard compliant ways to do
anything. Anything of that nature is off=topic, and may be found
on specialized news-groups dealing with the authors system.

You mean to say that any solution that requires non-standard compliant code
temporarily ceases to exist when talking on this NG and everyone trying to
predend they Do exist will be flamed for OT-talk?
That seems to be happening anyhow
 
C

CBFalconer

Harold said:
You mean to say that any solution that requires non-standard
compliant code temporarily ceases to exist when talking on this
NG and everyone trying to predend they Do exist will be flamed
for OT-talk? That seems to be happening anyhow

You've got it.
 

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
474,432
Messages
2,571,680
Members
48,796
Latest member
Greg L.

Latest Threads

Top