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

jt wrote:
> 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..??

Of course it is. Most viruses do.
But we will not tell you how.


-- 
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

On Sun, 03 Aug 2008 09:32:16 -0700, jt wrote:
> 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..

(I'll pretend you just wrote "the return address is saved" instead.)

Not on my system, and if it is on yours, consider getting a better 
compiler. It's possible for the compiler to either see that fun has no 
side effects and eliminate the call, or to inline fun. The former probably 
won't happen if you make fun actually do something, but the latter quite 
possibly will. If it is, there is no return address, so there is no 
location holding the return address.

> Is it possible to access this value..??

If the value exists at all, there is no standard way to access it. Some 
implementations have options for this; check the documentation. But even 
if you find it, what could you sensibly do with it?

jt wrote:

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

This needn't be so. The compiler could inline fun, eliminate it
altogether, store the "return address" on a different stack etc. IOW,
this is a detail of your implementation and it can vary in seemingly
unpredictable ways.

> Is it possible to access this value..??

Not from portable C code. You'll need to know in fair detail the calling
conventions for your implementation, and make sure that optimisations
like inlining are not in effect for this function. Practically
speaking, you'll have to learn the internals of your implementation and
the assembly language that is used on your system.

Some implementations provide convenient extensions for this purpose
(example, gcc's __builtin_return_address intrinsic), on others you may
have to resort inline assembler.

jacob navia wrote:

> jt wrote:
>> 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..??
> 
> Of course it is. Most viruses do.
> But we will not tell you how.

A truly determined and talented virus writer isn't going to be put off
by your answer. In fact, such persons probably won't post in this
group, in the first place. It's probable that curiosity is what's
motivating the OP to ask this question.

jt <karthiks.840@gmail.com> writes:
> 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..

Maybe, maybe not.  The language says only that after the function
finishes, execution continues after the call.  It says nothing about
how this is accomplished.  The C standard doesn't even mention a
"stack", and yes, there really are C implementations that don't use a
contiguously allocated hardware stack.

> Is it possible to access this value..??

It's not possible to access this value portably given the code you've
presented.

If you like, you can maintain your own stack of function addresses.
For example, on entry to each function, you can push the address of
the current function onto a stack (a data structure you can implement
in any of a variety of ways) of function pointers.  But this only
gives you the address of each *function*; it doesn't tell you where
within a function a call occurred.

Assuming the call to fun() isn't inlined, there's probably some
information somewhere in memory that's a close approximation of what
you're looking for.  As I said, there's no portable way to get at that
information.  A debugger (such as gdb) does maintain such information
and lets you display it as the program runs under its control, but it
uses an intimate knowledge of the particular system to do so.

If you have some real reason to access that kind of information
yourself, you'll have to ask in a forum that discusses the particular
system you're using -- and any information you get is likely to be
inapplicable to other systems.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

In article <g74rjg$o0p$2@registered.motzarella.org>,
santosh  <santosh.k83@gmail.com> wrote:
>jacob navia wrote:

>> jt wrote:

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

>> Of course it is. Most viruses do.
>> But we will not tell you how.

>A truly determined and talented virus writer isn't going to be put off
>by your answer. In fact, such persons probably won't post in this
>group, in the first place. It's probable that curiosity is what's
>motivating the OP to ask this question.

Why do you lock your car? A truly determined and talented car thief 
isn't going to be put off by the car door locks, and probably
wouldn't post about car door locks in public the first place.
It's probable that curiosity is what is motivating anyone asking
about car door locks -- so why not just leave your doors unlocked
or tell everyone where you hide the spare key?

I don't know about where you live, but where I live, there is a
serious problem with what are referred to as "joy riders" --
children 12 to 17 who wander around and when they see an
unprotected car, steal it and race around in it, abandoning
it somewhere else, usually after having banged up the car a bit
either through carelessness or as part of the "fun". This isn't just a
problem of a little bit of vandalism and "redistribution" of property:
there have been a number of high-speed police chases, and there have
been people killed by the crashes (these theives often don't
respect red lights.)

Is there a problem with professional car theives in this city? Yes.
But the professionals usually drive carefully, because they don't
want to attract attention to themselves.  There is a bigger problem
with the unprofessional joy riders. How do the joy-riders decide
what to steal? Answer: what-ever is most convenient. Left
your car running for 3 minutes while you dashed into a convenience
store to get a package of cigarettes? Good-bye car... Secured
your steering wheel with a locking device ("a club") while your
neighbour didn't bother? Good-bye your -neighbour's- car, yours
wasn't worth the bother to a joy rider.

Moral: If someone is determined to write a virus or similar,
at least make them *work* for it. Don't make it easy for people
to go joy-hacking: there are a lot of people who can't be bothered
to get serious about such things, but will do it if it is easy.
-- 
  "The quirks and arbitrariness we observe force us to the
  conclusion that ours is not the only universe." -- Walter Kistler

Walter Roberson wrote:

> In article <g74rjg$o0p$2@registered.motzarella.org>,
> santosh  <santosh.k83@gmail.com> wrote:
>>jacob navia wrote:
> 
>>> jt wrote:
> 
>>>> 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..??
> 
>>> Of course it is. Most viruses do.
>>> But we will not tell you how.
> 
>>A truly determined and talented virus writer isn't going to be put off
>>by your answer. In fact, such persons probably won't post in this
>>group, in the first place. It's probable that curiosity is what's
>>motivating the OP to ask this question.
> 
> Why do you lock your car? A truly determined and talented car thief
> isn't going to be put off by the car door locks, and probably
> wouldn't post about car door locks in public the first place.
> It's probable that curiosity is what is motivating anyone asking
> about car door locks -- so why not just leave your doors unlocked
> or tell everyone where you hide the spare key?

I hope you can see the difference between securing property and refusing
to answer a rather commonly asked question based on unwarranted
assumptions. Even if the OP were not given a single useful answer here,
it's still *trivially* easy to find out the details for his system.
Such information is available all over the Net. Besides getting at the
return address is only the first step to writing really good viruses -
they aren't as easy anymore as they once were. OTOH a locked car is
very difficult to steal, thus the precaution makes a great deal of
sense.

<snip>

> Moral: If someone is determined to write a virus or similar,
> at least make them *work* for it. Don't make it easy for people
> to go joy-hacking: there are a lot of people who can't be bothered
> to get serious about such things, but will do it if it is easy.

I think we differ as to whether the OP's question has a hidden agenda to
it or not. I took it at face value, as I myself have once considered
such matters out of sheer curiosity.

On 2008-08-03, Walter Roberson <roberson@ibd.nrc-cnrc.gc.ca> wrote:
> In article <g74rjg$o0p$2@registered.motzarella.org>,
> santosh  <santosh.k83@gmail.com> wrote:
>>jacob navia wrote:
>
>>> jt wrote:
>
>>>> 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..??
>
>>> Of course it is. Most viruses do.
>>> But we will not tell you how.
>
>>A truly determined and talented virus writer isn't going to be put off
>>by your answer. In fact, such persons probably won't post in this
>>group, in the first place. It's probable that curiosity is what's
>>motivating the OP to ask this question.
>
> Why do you lock your car? A truly determined and talented car thief 
> isn't going to be put off by the car door locks, and probably
> wouldn't post about car door locks in public the first place.
> It's probable that curiosity is what is motivating anyone asking
> about car door locks -- so why not just leave your doors unlocked
> or tell everyone where you hide the spare key?
>
> I don't know about where you live, but where I live, there is a
> serious problem with what are referred to as "joy riders" --
> children 12 to 17 who wander around and when they see an
> unprotected car, steal it and race around in it, abandoning
> it somewhere else, usually after having banged up the car a bit
> either through carelessness or as part of the "fun". This isn't just a
> problem of a little bit of vandalism and "redistribution" of property:
> there have been a number of high-speed police chases, and there have
> been people killed by the crashes (these theives often don't
> respect red lights.)
>
> Is there a problem with professional car theives in this city? Yes.
> But the professionals usually drive carefully, because they don't
> want to attract attention to themselves.  There is a bigger problem
> with the unprofessional joy riders. How do the joy-riders decide
> what to steal? Answer: what-ever is most convenient. Left
> your car running for 3 minutes while you dashed into a convenience
> store to get a package of cigarettes? Good-bye car... Secured
> your steering wheel with a locking device ("a club") while your
> neighbour didn't bother? Good-bye your -neighbour's- car, yours
> wasn't worth the bother to a joy rider.
>
> Moral: If someone is determined to write a virus or similar,
> at least make them *work* for it. Don't make it easy for people
> to go joy-hacking: there are a lot of people who can't be bothered
> to get serious about such things, but will do it if it is easy.

My last job (hacking Plan 9 kernel stuff) involved essentially this
same problem. I ended up diddling the stack in assembly to save time,
but I spent quite a while researching what happens to the stack
when you call functions; the original plan was to mess with the
stack from within a C function, making the entire thing portable.
(We were writing a kernel tracing/profiling device that did some
stuff whenever a function was called or exited).

It's not all about viruses.

John

In article <3865df3f-4d18-4e8e-ad74-7c2884491890@v1g2000pra.googlegroups.com>
jt  <karthiks.840@gmail.com> wrote:
>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..

Actually, it is put in the register "lr" (PPC), "ra" (MIPS), "%o7"
(SPARC), or 14 (IBM S/390; spelled %r14 in GNU assembler).  As
others have noted, if fun() is expanded in line, there is no control
transfer at all.  But on the VAX and PDP-11, it is indeed placed
on the (hardware) stack.

>Is it possible to access this value..??

Clearly, if it is accessible at all, the method will vary, since
it is in different places on each of these architectures.
-- 
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40�39.22'N, 111�50.29'W)  +1 801 277 2603
email: gmail (figure it out)      http://web.torek.net/torek/index.html

"Chris Torek" <nospam@torek.net> wrote in message 
news:g75g800g5p@news3.newsguy.com...
> In article 
> <3865df3f-4d18-4e8e-ad74-7c2884491890@v1g2000pra.googlegroups.com>
> jt  <karthiks.840@gmail.com> wrote:
>>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..
>
> Actually, it is put in the register "lr" (PPC), "ra" (MIPS), "%o7"
> (SPARC), or 14 (IBM S/390; spelled %r14 in GNU assembler).  As
> others have noted, if fun() is expanded in line, there is no control
> transfer at all.  But on the VAX and PDP-11, it is indeed placed
> on the (hardware) stack.

You left out x86-32. A little-used processor, I know...

-- 
Bartc

"jt" <karthiks.840@gmail.com> wrote in message 
news:3865df3f-4d18-4e8e-ad74-7c2884491890@v1g2000pra.googlegroups.com...
> 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..??

We've had a lot of "not in standard C" responses now.. what use are they?

Your compiler may have the intrinsic function _ReturnAddress() (and/or 
_AddressOfReturnAddress() ) available
You can also try to access 'the address of the last argument + its size' as 
though it was a pointer-sized thing but that's less stable and very 
implementation dependand 

Harold Aptroot wrote:

> "jt" <karthiks.840@gmail.com> wrote in message
>
news:3865df3f-4d18-4e8e-ad74-7c2884491890@v1g2000pra.googlegroups.com...
>> 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..??
> 
> We've had a lot of "not in standard C" responses now.. what use are
> they?

If they manage to redirect the OP to a more suitable forum, then IMO,
they served their purpose.

> Your compiler may have the intrinsic function _ReturnAddress() (and/or
> _AddressOfReturnAddress() ) available

Which compiler has the latter function (just curious)?

> You can also try to access 'the address of the last argument + its
> size' as though it was a pointer-sized thing but that's less stable
> and very implementation dependand

This is probably the worst method (if once could call it that) that I've
seen so far.

The return address is a feature of the *implementation* , which in the
vast majority of cases uses features of the underlying processor to
accomplish this. Thus for a robust solution to the OP's problem, one
needs to determine the details of the implementation and the underlying
hardware.

jacob navia schrieb:

> Of course it is. Most viruses do.
> But we will not tell you how.

No. Most viruses don't. Many worms do.

Regards,
Johannes

-- 
"Wer etwas kritisiert muss es noch lange nicht selber besser k�nnen. Es
reicht zu wissen, da� andere es besser k�nnen und andere es auch
besser machen um einen Vergleich zu bringen."     -     Wolfgang Gerber
       in de.sci.electronics <47fa8447$0$11545$9b622d9e@news.freenet.de>

> Is it possible to access this value..??

No.

"santosh" <santosh.k83@gmail.com> wrote in message 
news:g766gb$jr8$1@registered.motzarella.org...
> Harold Aptroot wrote:
>
>> "jt" <karthiks.840@gmail.com> wrote in message
>>
> news:3865df3f-4d18-4e8e-ad74-7c2884491890@v1g2000pra.googlegroups.com...
>>> 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..??
>>
>> We've had a lot of "not in standard C" responses now.. what use are
>> they?
>
> If they manage to redirect the OP to a more suitable forum, then IMO,
> they served their purpose.

And the OP still wouldn't know anything
Which is great, because most people in clc are just here to flame people who 
ask questions that in their opinion don't belong there - without answering 
them first.

>
>> Your compiler may have the intrinsic function _ReturnAddress() (and/or
>> _AddressOfReturnAddress() ) available
>
> Which compiler has the latter function (just curious)?

Some versions of MSVC

>> You can also try to access 'the address of the last argument + its
>> size' as though it was a pointer-sized thing but that's less stable
>> and very implementation dependand
>
> This is probably the worst method (if once could call it that) that I've
> seen so far.

It's very bad
I've seen it work though, and that's all that really matters (most virusses 
are platform specific anyway)


> The return address is a feature of the *implementation* , which in the
> vast majority of cases uses features of the underlying processor to
> accomplish this. Thus for a robust solution to the OP's problem, one
> needs to determine the details of the implementation and the underlying
> hardware.

Or just assume it'll be the most common implementation and let the OP 
complain when that assumption turns out to be false?

An other solution that will not sit well with C-purists but should work:
inline assembly! 

"MisterE" <MisterE@nimga.com> wrote in message 
news:4896ea8f$0$11888$afc38c87@news.optusnet.com.au...
>
>> Is it possible to access this value..??
>
> No.
>

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

Harold Aptroot wrote:
> "santosh" <santosh.k83@gmail.com> wrote in message 
> news:g766gb$jr8$1@registered.motzarella.org...
>> Harold Aptroot wrote:
>>
>>> "jt" <karthiks.840@gmail.com> wrote in message
>>>
>> news:3865df3f-4d18-4e8e-ad74-7c2884491890@v1g2000pra.googlegroups.com...
>>>> 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..??
>>>
>>> We've had a lot of "not in standard C" responses now.. what use are
>>> they?
>>
>> If they manage to redirect the OP to a more suitable forum, then IMO,
>> they served their purpose.
> 
> And the OP still wouldn't know anything

     The O.P. has learned that his problem cannot be solved
with unaided C.  The O.P. has also been directed to a place
where he might learn more.

     Look at it this way: When you conduct a Google search you
do not receive information about the subject you searched for.
Rather, you receive a whole bunch of pointers to other places
that might provide information.  Since Google gives the searcher
only links but no actual data, do you consider Google useless?

> Which is great, because most people in clc are just here to flame people 
> who ask questions that in their opinion don't belong there - without 
> answering them first.

     I think not.  There are some who visit this newsgroup for
nothing more (it seems) than the sheer joy of polluting; they
have found their way into my killfile.  But my killfile for this
group has only (checks) four entries, so I take issue with your
use of "most" and suggest "some" as an alternative.

 > [...]
> An other solution that will not sit well with C-purists but should work:
> inline assembly!

     Still better would be inline COBOL, which at least has
a "C" in it.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

"Harold Aptroot" <harold.aptroot@gmail.com> writes:
> "santosh" <santosh.k83@gmail.com> wrote in message
> news:g766gb$jr8$1@registered.motzarella.org...
>> Harold Aptroot wrote:
[...]
>>> We've had a lot of "not in standard C" responses now.. what use are
>>> they?
>>
>> If they manage to redirect the OP to a more suitable forum, then IMO,
>> they served their purpose.
>
> And the OP still wouldn't know anything
[...]

Nonsense.  The OP has already gotten the best answer we can give him
with regard to the C language, that it provides no portable way to get
the return address.  He's far more likely to get a *useful* answer
that will help him do what he wants to do by posting to a more
suitable forum.

As for the multiplicity of answers saying essentially the same thing,
that's a consequence of the fact that Usenet is asynchronous; several
people post answers before seeing the others.  There's no easy
solution to this in an unmoderated newsgroup.  (I note that
comp.lang.c.moderated has even more of a problem with multiple similar
answers than comp.lang.c does, because of long latency and the
moderator's choice not to reject duplicate answers.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

jt wrote:
> 
> 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..??

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.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.

Harold Aptroot wrote:
> "MisterE" <MisterE@nimga.com> wrote in message
>
>>> Is it possible to access this 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, and may be found
on specialized news-groups dealing with the authors system.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.

On Mon, 04 Aug 2008 17:42:31 -0400, CBFalconer wrote:
> Harold Aptroot wrote:
>> "MisterE" <MisterE@nimga.com> wrote in message
>>>> Is it possible to access this 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. 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.

CBFalconer <cbfalconer@yahoo.com> writes:

> Harold Aptroot wrote:
>> "MisterE" <MisterE@nimga.com> wrote in message
>>
>>>> Is it possible to access this 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, 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.

CBFalconer <cbfalconer@yahoo.com> writes:
> Harold Aptroot wrote:
>> "MisterE" <MisterE@nimga.com> wrote in message
>>>> Is it possible to access this 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, 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.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

In article <lnvdyg8hc0.fsf@nuthaus.mib.org>,
Keith Thompson  <kst-u@mib.org> wrote:

>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.
-- 
  "You may comand nature to the extent only in which you are willing to
  obey her."                                  -- Walter Russell

Keith Thompson wrote:
> CBFalconer <cbfalconer@yahoo.com> writes:
>
.... snip ...
>
>> 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.
> 
.... 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.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.

On 4 Aug, 23:25, Harald van D=A9=A6k <true...@gmail.com> wrote:
> On Mon, 04 Aug 2008 17:42:31 -0400, CBFalconer wrote:
> > Harold Aptroot wrote:
> >> "MisterE" <Mist...@nimga.com> 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 d=
o
> >> it after all
>
> > On this newsgroup, there are no non-standard compliant ways to do
> > anything.  Anything of that nature is off=3Dtopic,
>
> 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)

On 4 Aug, 22:30, CBFalconer <cbfalco...@yahoo.com> wrote:
> jt wrote:

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

Nick Keighley wrote:

> On 4 Aug, 22:30, CBFalconer <cbfalco...@yahoo.com> wrote:
>> jt wrote:
> 
>> > 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..??
>>
>> 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.

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.

-- 
'It changed the future .. and it changed us.'               /Babylon 5/

Hewlett-Packard Limited registered office:                Cain Road, Bracknell,
registered no: 690597 England                                    Berks RG12 1HN

Nick Keighley wrote:

> On 4 Aug, 22:30, CBFalconer <cbfalco...@yahoo.com> wrote:
>> jt wrote:
> 
>> > 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..??
>>
>> 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.

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

Chris Dollin wrote:

> Nick Keighley wrote:
> 
>> On 4 Aug, 22:30, CBFalconer <cbfalco...@yahoo.com> wrote:
>>> jt wrote:
>> 
>>> > 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..??
>>>
>>> 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.
> 
> 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.
> 

"Nick Keighley" <nick_keighley_nospam@hotmail.com> wrote in message 
news:57a73729-e6a7-4726-ae3d-14f95374bfac@a1g2000hsb.googlegroups.com...
> On 4 Aug, 23:25, Harald van D��k <true...@gmail.com> wrote:
>> On Mon, 04 Aug 2008 17:42:31 -0400, CBFalconer wrote:
>> > Harold Aptroot wrote:
>> >> "MisterE" <Mist...@nimga.com> 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?

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

"jt" <karthiks.840@gmail.com> wrote in message 
news:3865df3f-4d18-4e8e-ad74-7c2884491890@v1g2000pra.googlegroups.com...
> 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...

-- 
Bartc 

Harold Aptroot wrote:

> "Nick Keighley" <nick_keighley_nospam@hotmail.com> wrote in message
>
news:57a73729-e6a7-4726-ae3d-14f95374bfac@a1g2000hsb.googlegroups.com...
>> On 4 Aug, 23:25, Harald van D?k <true...@gmail.com> wrote:
>>> On Mon, 04 Aug 2008 17:42:31 -0400, CBFalconer wrote:
>>> > Harold Aptroot wrote:
>>> >> "MisterE" <Mist...@nimga.com> 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.

Bartc wrote:

> 
> "jt" <karthiks.840@gmail.com> wrote in message
>
news:3865df3f-4d18-4e8e-ad74-7c2884491890@v1g2000pra.googlegroups.com...
>> 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...

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

Harold Aptroot said:

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

Forget better mousetraps. If you can demonstrate how to make coffee in ISO 
C, the world will build a six-lane motorway to your door.

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

"santosh" <santosh.k83@gmail.com> wrote in message 
news:g79b7v$ul8$2@registered.motzarella.org...
> Harold Aptroot wrote:
>
>> "Nick Keighley" <nick_keighley_nospam@hotmail.com> wrote in message
>>
> news:57a73729-e6a7-4726-ae3d-14f95374bfac@a1g2000hsb.googlegroups.com...
>>> On 4 Aug, 23:25, Harald van D?k <true...@gmail.com> wrote:
>>>> On Mon, 04 Aug 2008 17:42:31 -0400, CBFalconer wrote:
>>>> > Harold Aptroot wrote:
>>>> >> "MisterE" <Mist...@nimga.com> 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.

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

Harold Aptroot wrote:
> "santosh" <santosh.k83@gmail.com> wrote in message
> news:g79b7v$ul8$2@registered.motzarella.org...
>> Harold Aptroot wrote:
>>>>> >> "MisterE" <Mist...@nimga.com> wrote in message
>>>>
>>>>> >>>> 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.

santosh wrote:

> Chris Dollin wrote:

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

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.

-- 
'It changed the future .. and it changed us.'               /Babylon 5/

Hewlett-Packard Limited                                          registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN          690597 England

Chris Dollin wrote:

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

-- 
'It changed the future .. and it changed us.'               /Babylon 5/

Hewlett-Packard Limited                                          registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN          690597 England

"CBFalconer" <cbfalconer@yahoo.com> wrote in message 
news:489777C7.1CCEC104@yahoo.com...
> Harold Aptroot wrote:
>> "MisterE" <MisterE@nimga.com> wrote in message
>>
>>>> Is it possible to access this 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, 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 

Harold Aptroot wrote:
> "CBFalconer" <cbfalconer@yahoo.com> wrote in message
>> Harold Aptroot wrote:
>>
.... snip ...
>>
>> 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

You've got it.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.

CBFalconer <cbfalconer@yahoo.com> writes:
> Keith Thompson wrote:
>> CBFalconer <cbfalconer@yahoo.com> writes:
>>
> ... snip ...
>>
>>> 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.
>> 
> ... 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.

MisterE's response was just "No.", with no elaboration.  You appeared
to be defending that response.  Perhaps that wasn't your intent.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

roberson@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:
> In article <lnvdyg8hc0.fsf@nuthaus.mib.org>,
> Keith Thompson  <kst-u@mib.org> wrote:
>
>>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.

Well, the function itself must be able to get at the return address in
order to return to it, but that doesn't necessarily mean it's possible
to retrieve that address.

My assumption is that it's always possible, but I could well be
mistaken.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Harold Aptroot wrote:
> 
> 
> "CBFalconer" <cbfalconer@yahoo.com> wrote in message 
> news:489777C7.1CCEC104@yahoo.com...
>> Harold Aptroot wrote:
>>> "MisterE" <MisterE@nimga.com> wrote in message
>>>
>>>>> Is it possible to access this 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, 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

     For my part, I draw the line a little more leniently than
CBF does.  Nonetheless, I maintain that the line is a useful one:
There is an important distinction between things that can be done
with unaided C and things that require additional machinery or
additional assumptions.

     The reason the distinction is important is that engineering
is an art of trade-offs, and the trade-offs should be made with
proper consideration and not out of ignorance.  If you know that
doing a task in some particular way involves things C doesn't
provide or guarantee, then you can make a conscious assessment
about whether the increased capability justifies the diminished
portability.  But if you *don't* know where the line is, you'll
wander across it all unaware, perhaps to be unpleasantly surprised
when your code doesn't work on the next machine.  You need to be
aware of the boundary, so that you cross it only by decision and
not by accident.

     Another reason to study the distinction is that the category
of things unaided C can do is larger than some people imagine.
For example, people are always asking how to discover a machine's
endianness so they can write code that swings both ways.  Usually
they're shown a couple of tricks for testing and byte-swapping and
so on -- but often they're also shown "endian-blind" code that
just plain works, no matter how the underlying machine arranges
its integers.  That is, they're shown an unaided-C way to solve a
problem that they originally thought needed machine-specific hacks.
That sort of improvement is a worthwhile gain, and should motivate
any serious practitioner to become more familiar with his tools.

     Finally, when somebody wants to do something that unaided C
cannot do or cannot do well, the helpful response is to let them
know it's beyond the capabilities of unaided C and to refer them,
if possible, to sources where they can get more information about
the beyond-C capabilities they need.  The alternative of dragging
all the beyond-C things into this group is not viable, simply
because the experts in those beyond-C things don't hang out here.
Among the people who frequent this group there are probably folks
who know quite a bit about networking, cryptography, numerical
analysis, random number generation, parsing of artificial and
natural languages, hardware-assisted 3D rendering, and on and on
and on.  That's fine, and I for one am glad of their presence.
But the experts in any one such field are thin on the ground here,
not surrounded by their fellow experts who might clarify or correct
their responses.  If somebody's working on a C program to reckon
dates according to ancient Babylonian calendars, this is a fine
forum for dealing with the C problems but not a good one for the
calendrical questions.  There's probably someone here who knows
about Babylonian calendars and he might answer the question, but
there's nobody here to say "No, that's how the Sumerians did it;
the Babylonian system was quite different."

     This group attracts (as it is intended to) a congregation of
people interested in and to varying degrees expert in C, and is
a splendid forum for C questions.  Questions about shells, shared
memory, threads, eigenvalue computation, texture mapping, and the
approved protocols for financial computation belong elsewhere.
Because despite our high opinions of ourselves ("Hey, I can write
C -- I must be Really Smart!"), we don't quite Know It All.

-- 
Eric.Sosman@sun.com

santosh <santosh.k83@gmail.com> writes:
> Nick Keighley wrote:
>> On 4 Aug, 22:30, CBFalconer <cbfalco...@yahoo.com> wrote:
>>> jt wrote:
>> 
>>> > 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..??
>>>
>>> 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.
>
> And it must also *behave* like a LIFO data structure. So at least a
> software based stack is necessary.

The word "stack" is commonly used in two different ways.

It can refer to a LIFO data structure, regardless of how it's
represented.  A C implementation needs one of these to handle
recursive calls, and most likely all calls.  (If a program can be
proven to have no recursive calls, an implementation might avoid the
use of a stack; this would make sense only if using a stack led to
relatively inefficent code.)

It can also refer to a specific implementation of a LIFO data
structure, as a contiguous chunk of memory that grows in a particular
direction, typically managed via a hardware stack pointer register.
The phrase "the stack" usually refers to this kind of stack, and I'm
sure it's what the OP was referring to when he said that "the return
address is pushed to the stack".  C doesn't require this kind of
stack, and some real-world implementations don't use it.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Eric Sosman wrote:

<snip>

An excellent post. Should probably be kept around as a canned response
for the all too frequent topicality debates.

santosh said:

> Eric Sosman wrote:
> 
> <snip>
> 
> An excellent post.

I agree.

> Should probably be kept around as a canned response
> for the all too frequent topicality debates.

It's considerably less than a year ago that we discussed topicality at some 
length. Everyone had a chance to have their say, and many people availed 
themselves of that opportunity. I see no reason why it needs to be dragged 
up again for the time being. Once a year ought to be enough for anybody.

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

Richard Heathfield <rjh@see.sig.invalid> writes:

> santosh said:
>
>> Eric Sosman wrote:
>> 
>> <snip>
>> 
>> An excellent post.
>
> I agree.
>
>> Should probably be kept around as a canned response
>> for the all too frequent topicality debates.
>
> It's considerably less than a year ago that we discussed topicality at some 
> length. Everyone had a chance to have their say, and many people availed 
> themselves of that opportunity. I see no reason why it needs to be dragged 
> up again for the time being. Once a year ought to be enough for anybody.

Are you related to Robert Mugabe by any chance?

In article <g79t2k$f0u$1@registered.motzarella.org>,
Richard <rgrdev@gmail.com> wrote:
>Richard Heathfield <rjh@see.sig.invalid> writes:

>> It's considerably less than a year ago that we discussed topicality at some 
>> length. Everyone had a chance to have their say, and many people availed 
>> themselves of that opportunity. I see no reason why it needs to be dragged 
>> up again for the time being. Once a year ought to be enough for anybody.

>Are you related to Robert Mugabe by any chance?

In my opinion, that was a completely unnecessary and extreme insult.

Richard Heathfield expressed an opinion, something that he is
entitled to do in democratic societies. The opinion was not 
inherently inflamatory or inherently unreasonable: it was well
within the bounds of what might be believed by a "reasonable person
in full possession of the facts". I have seen no evidence to
suggest that Richard Heathfield is somehow forcing his opinion
upon others or defrauding others or changing rules post facto.

If you disagree with Richard Heathfield about the frequency of
reasonable debate upon topicality, then you could simply state
the frequency which you feel is appropriate and give reasons thereto.
But Richard Heathfield is correct, that the matter did get discussed
at length not long ago, and the majority opinion expressed was in
favour of strict topicality, so be aware that if your answer
about reasonable frequency of topicality debates is "anytime", then
there is a distinct risk that you would be viewed as being unconcerned
with what the majority expressed and instead only interested in
having *your* viewpoint adopted.
-- 
  "The quirks and arbitrariness we observe force us to the
  conclusion that ours is not the only universe." -- Walter Kistler

roberson@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:

> In article <g79t2k$f0u$1@registered.motzarella.org>,
> Richard <rgrdev@gmail.com> wrote:
>>Richard Heathfield <rjh@see.sig.invalid> writes:
>
>>> It's considerably less than a year ago that we discussed topicality at some 
>>> length. Everyone had a chance to have their say, and many people availed 
>>> themselves of that opportunity. I see no reason why it needs to be dragged 
>>> up again for the time being. Once a year ought to be enough for anybody.
>
>>Are you related to Robert Mugabe by any chance?
>
> In my opinion, that was a completely unnecessary and extreme insult.

Get off your high horse. It was a quip. Does your sense of humour not
meet the C Standard and you leave it at the door?

>
> Richard Heathfield expressed an opinion, something that he is
> entitled to do in democratic societies. The opinion was not 
> inherently inflamatory or inherently unreasonable: it was well
> within the bounds of what might be believed by a "reasonable person
> in full possession of the facts". I have seen no evidence to
> suggest that Richard Heathfield is somehow forcing his opinion
> upon others or defrauding others or changing rules post facto.

Heathfield trots out the vote thing time after time. The only people
interested enough were the usual c.l.c clique. It proved nothing.

Keith Thompson wrote, On 05/08/08 16:10:
> roberson@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:
>> In article <lnvdyg8hc0.fsf@nuthaus.mib.org>,
>> Keith Thompson  <kst-u@mib.org> wrote:
>>
>>> 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.
> 
> Well, the function itself must be able to get at the return address in
> order to return to it, but that doesn't necessarily mean it's possible
> to retrieve that address.
> 
> My assumption is that it's always possible, but I could well be
> mistaken.

I know of one implementation where it is definitely *not* possible 
without resort to assembler for all functions and there is not always an 
easy way to determine if it is possible. The reason it is not always 
possible is that the processor has an 8 deep HW stack for return 
addresses which is *not* mapped in to any of the address spaces (it can 
only be accessed by call, return, push and pop type assembler 
instructions). The compiler will pop return addresses of the stack if 
the function calls other functions *unless* it only calls functions from 
the provided C library *and* it knows those functions will not cause the 
HW stack to overflow. So if a function calls only library functions you 
would have to either examine the generated code or determine what the 
compiler knows about the library functions which are called to determine 
whether the return address is on the HW stack or has been popped of the 
HW stack on to the SW stack.

So I would say that on this particular implementation it is impossible 
in general without resorting to assembler (as opposed to non-portable C 
constructs).

Oh, and this is ignoring the possibility someone else raised that the 
function might have been inlined, something that can cause problems with 
the non-portable extension provided by at least one implementation for 
this purpose :-)

OK, now which of these stacks is *the* stack? ;-)
-- 
Flash Gordon

In article <g7a2d3$vlh$1@registered.motzarella.org>,
Richard <rgrdev@gmail.com> wrote:
>roberson@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:

>> In article <g79t2k$f0u$1@registered.motzarella.org>,
>> Richard <rgrdev@gmail.com> wrote:
>>>Richard Heathfield <rjh@see.sig.invalid> writes:

>>>Are you related to Robert Mugabe by any chance?

>> In my opinion, that was a completely unnecessary and extreme insult.

>Get off your high horse. It was a quip.

Regardless of what you might have -thought- you were posting, what
you *did* post was (in my opinion) a distinct insult, not a quip.
Personally, I don't believe you intended it as humour.


>Heathfield trots out the vote thing time after time. The only people
>interested enough were the usual c.l.c clique. It proved nothing.

If you re-examine the postings from that time, I believe you will
find that a large number of people contributed, including a number
that do not contribute very often. It was -not- "the usual c.l.c clique".

Your argument is treading close to the old claim of there being a
"silent majority" that support your position but whom didn't speak up.

If, hypothetically, the strict-topicality stance is what is desired
by the majority of readers, what evidence would you require to
be satisfied that that was the case? What evidence would
be you accept as "proving" something?
-- 
  "Every intellectual product must be judged from the point of view
  of the age and the people in which it was produced."
                                              -- Walter Horatio Pater

Walter Roberson wrote:

> In article <g7a2d3$vlh$1@registered.motzarella.org>,
> Richard <rgrdev@gmail.com> wrote:

> > Get off your high horse. It was a quip.
> 
> Regardless of what you might have -thought- you were posting, what
> you did post was (in my opinion) a distinct insult, not a quip.
> Personally, I don't believe you intended it as humour.

Trolls, feed, don't, please, yadda, yadda.




Brian

Walter Roberson said:

> In article <g7a2d3$vlh$1@registered.motzarella.org>,
> Richard <rgrdev@gmail.com> wrote:

<snip>

>>Heathfield trots out the vote thing time after time. The only people
>>interested enough were the usual c.l.c clique. It proved nothing.
> 
> If you re-examine the postings from that time, I believe you will
> find that a large number of people contributed, including a number
> that do not contribute very often. It was -not- "the usual c.l.c clique".

Right, it wasn't. And several people (including myself) did express a view 
that was not in accordance with the majority view. Richard NoSurname Riley 
expressed a view in that thread, however, and so either he's mistaken in 
his belief that the only ones interested were what he calls the clc 
clique, or he believes that he's part of that clique. Either way, during 
that debate he expressed an interest in topicality that was not 
significantly more liberal than my own view.

> Your argument is treading close to the old claim of there being a
> "silent majority" that support your position but whom didn't speak up.

"The lurkers support me in email" is worth a Web search - sung to the tune 
of "My bonny lies over the ocean".

> If, hypothetically, the strict-topicality stance is what is desired
> by the majority of readers, what evidence would you require to
> be satisfied that that was the case? What evidence would
> be you accept as "proving" something?

It is clear that no amount of evidence will convince him, because his 
position is based not on logic but on a negative emotional reaction to the 
posting styles of some of the people here - hence his pointlessly contrary 
and vehemently held positions on so many issues.

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

CBFalconer <cbfalconer@yahoo.com> writes:
> Harold Aptroot wrote:
>> "CBFalconer" <cbfalconer@yahoo.com> wrote in message
>>> Harold Aptroot wrote:
>>>
> ... snip ...
>>>
>>> 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
>
> You've got it.

MisterE's reply clearly implied that it cannot be done at all.  Apart
from being factually incorrect, his reply was off-topic -- unless you
can cite chapter and verse in the ISO C standard to support his
assertion that you can't access a function's return address *even
using non-portable code*.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Walter Roberson wrote:
> Richard <rgrdev@gmail.com> wrote:
>> roberson@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:
>>> Richard <rgrdev@gmail.com> wrote:
>>>
.... snip ...
>>> 
>>>> Are you related to Robert Mugabe by any chance?
>>>
>>> In my opinion, that was a completely unnecessary and extreme
>>> insult.
>>
>> Get off your high horse. It was a quip.
> 
> Regardless of what you might have -thought- you were posting,
> what you *did* post was (in my opinion) a distinct insult, not
> a quip.  Personally, I don't believe you intended it as humour.

I suggest plonking "Richard <rgrdev@gmail.com>".  Then you will
only see his nonsense in others quotes.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.

On  5 Aug 2008 at 18:18, Walter Roberson wrote:
> Richard <rgrdev@gmail.com> wrote:
>>roberson@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:
>>> Richard <rgrdev@gmail.com> wrote:
>>>>Richard Heathfield <rjh@see.sig.invalid> writes:
>
>>>>Are you related to Robert Mugabe by any chance?
>
>>> In my opinion, that was a completely unnecessary and extreme insult.
>
>>Get off your high horse. It was a quip.
>
> Regardless of what you might have -thought- you were posting, what
> you *did* post was (in my opinion) a distinct insult, not a quip.
> Personally, I don't believe you intended it as humour.

When humor cuts close to the bone, there's a fine line between being
funny and being all too true.

It's clear that there are definite parallels: the self-belief in their
unutterable correctness, as well as the nasty methods they use to attack
their enemies - Mugabe phsyically, Heathfield through a continued
undermining of the reputation of his "adversaries" (i.e. those who dare
to disagree with him).

>>Heathfield trots out the vote thing time after time. The only people
>>interested enough were the usual c.l.c clique. It proved nothing.
>
> If you re-examine the postings from that time, I believe you will
> find that a large number of people contributed, including a number
> that do not contribute very often. It was -not- "the usual c.l.c clique".

By your estimation, how many lurkers does this group have for each
regular poster? What, therefore, was the percentage turnout at this
"election" in which Heathfield (like Mugabe) was judge, jury and the
only possible victor?

> Your argument is treading close to the old claim of there being a
> "silent majority" that support your position but whom didn't speak up.

No less true for being old.

> If, hypothetically, the strict-topicality stance is what is desired
> by the majority of readers, what evidence would you require to
> be satisfied that that was the case? What evidence would
> be you accept as "proving" something?

It's impossible to "prove" this either way, just as it's impossible to
say whether the number of babies born in Swaziland yesterday was even
or odd - we have no way of collecting the data.

On  5 Aug 2008 at 19:37, Default User wrote:
> Trolls, feed, don't, please, yadda, yadda.

Screw, go, yourself, please, yadda, yadda.

On Tue, 05 Aug 2008 01:52:26 -0700, Nick Keighley wrote:
> On 4 Aug, 23:25, Harald van Dijk <true...@gmail.com> wrote:
>> On Mon, 04 Aug 2008 17:42:31 -0400, CBFalconer wrote:
>> > Harold Aptroot wrote:
>> >> "MisterE" <Mist...@nimga.com> 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.

My statement?

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

"There is no way to do it that is topical to this NG" and "There is no way 
to do it" are very different. The former I have no problem with. The 
latter I do, particularly because it suggests that there are no relevant 
points to the question outside of the bounds of this group's topicality. 
In other words, given "no" as an answer, there is no reason to try asking 
on other groups.

> Though I must admit
> I'd have suggested trying another NG.

That's what I'm after.

On Tue, 05 Aug 2008 15:47:57 +0000, Richard Heathfield wrote:
> 
> It's considerably less than a year ago that we discussed topicality at some 
> length. Everyone had a chance to have their say, and many people availed 
> themselves of that opportunity.

MID please?

Anand Hariharan said:

> On Tue, 05 Aug 2008 15:47:57 +0000, Richard Heathfield wrote:
>> 
>> It's considerably less than a year ago that we discussed topicality at
>> some length. Everyone had a chance to have their say, and many people
>> availed themselves of that opportunity.
> 
> MID please?

Gladly.

<Q4GdnReyhdEy0mPbnZ2dnUVZ8v6dnZ2d@bt.com> (posted on 29 September 2007) 
begins a thread of over 200 articles, most of which are from people whose 
views on topicality are rather more strict than mine.

<acOdnb474quom5_anZ2dneKdnZydnZ2d@bt.com> (posted a few days later) 
contains a brief tabulated summary of views expressed in the earlier 
thread. You will be glad to hear that it has far fewer followups than the 
first thread.

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

Keith Thompson wrote:
> CBFalconer <cbfalconer@yahoo.com> writes:
>> Harold Aptroot wrote:
>>> "CBFalconer" <cbfalconer@yahoo.com> wrote in message
>>>
>> ... snip ...
>>>>
>>>> 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
>>
>> You've got it.
> 
> MisterE's reply clearly implied that it cannot be done at all. 
> Apart from being factually incorrect, his reply was off-topic --
> unless you can cite chapter and verse in the ISO C standard to
> support his assertion that you can't access a function's return
> address *even using non-portable code*.

I disagree.  First, there is nothing from MisterE in the quotes
above, so anything he said is not applicable (nor in my earlier
here-quoted messages).  I said 'on this newsgroup' and 'specialized
news-groups dealing with'.  I then agreed with Mr. Aptroots
non-enthusiastic comment.

The quotation attributions above seem accurate to me.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.

Richard wrote:

> Are you related to Robert Mugabe by any chance?

Any doubts I had about you being a deliberate trouble-maker
have been smashed, burnt, and the smoke thrown into the Sun.

If you thought that was /funny/, I have no hope for you.

-- 
'It changed the future .. and it changed us.'               /Babylon 5/

Hewlett-Packard Limited                                          registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN          690597 England

On 3 Aug 2008 23:50:24 GMT, Chris Torek <nospam@torek.net> wrote:

> In article <3865df3f-4d18-4e8e-ad74-7c2884491890@v1g2000pra.googlegroups.com>
> jt  <karthiks.840@gmail.com> wrote:
<snip>
> >the return address is pushed to the stack..
> 
> Actually, it is put in the register "lr" (PPC), "ra" (MIPS), "%o7"
> (SPARC), or 14 (IBM S/390; spelled %r14 in GNU assembler).  As

S/360,370,390 by convention only; the hardware is equally happy with
any GPR except 0. IIUC zSeries has some new options (insns) also.

> others have noted, if fun() is expanded in line, there is no control
> transfer at all.  But on the VAX and PDP-11, it is indeed placed
> on the (hardware) stack.
> 
In PDP-11 it can be pushed, or stored to any of R0 .. R5 and that
register's previous contents pushed (instead). I believe that C on
early-Unix -- around 6/7ed? -- used R5, although if I ever knew why
I've forgotten. (And that's why at most 3 'register' declarations were
effective, using R2..R4, with at least R0&R1 left for expr eval.)

PDP-8 stores it into the first word of the callee routine. But since
the -8 supports at most 48K-octets of storage a conforming C89
implementation would be challenging and C99 out of the question.

- formerly david.thompson1 || achar(64) || worldnet.att.net