473,320 Members | 2,052 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.

stack

jt
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..??
Aug 3 '08 #1
62 2772
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
Aug 3 '08 #2
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?
Aug 3 '08 #3
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.

Aug 3 '08 #4
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.

Aug 3 '08 #5
jt <ka**********@gmail.comwrites:
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) ks***@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"
Aug 3 '08 #6
In article <g7**********@registered.motzarella.org>,
santosh <sa*********@gmail.comwrote:
>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
Aug 3 '08 #7
Walter Roberson wrote:
In article <g7**********@registered.motzarella.org>,
santosh <sa*********@gmail.comwrote:
>>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.

Aug 3 '08 #8
On 2008-08-03, Walter Roberson <ro******@ibd.nrc-cnrc.gc.cawrote:
In article <g7**********@registered.motzarella.org>,
santosh <sa*********@gmail.comwrote:
>>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
Aug 3 '08 #9
In article <38**********************************@v1g2000pra.g ooglegroups.com>
jt <ka**********@gmail.comwrote:
>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
Aug 3 '08 #10
"Chris Torek" <no****@torek.netwrote in message
news:g7********@news3.newsguy.com...
In article
<38**********************************@v1g2000pra.g ooglegroups.com>
jt <ka**********@gmail.comwrote:
>>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

Aug 4 '08 #11
"jt" <ka**********@gmail.comwrote in message
news:38**********************************@v1g2000p ra.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

Aug 4 '08 #12
Harold Aptroot wrote:
"jt" <ka**********@gmail.comwrote in message
news:38**********************************@v1g2000p ra.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.

Aug 4 '08 #13
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 <47***********************@news.freenet.de>
Aug 4 '08 #14
Is it possible to access this value..??
No.
Aug 4 '08 #15
"santosh" <sa*********@gmail.comwrote in message
news:g7**********@registered.motzarella.org...
Harold Aptroot wrote:
>"jt" <ka**********@gmail.comwrote in message
news:38**********************************@v1g2000p ra.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!

Aug 4 '08 #16
"MisterE" <Mi*****@nimga.comwrote in message
news:48***********************@news.optusnet.com.a u...
>
>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

Aug 4 '08 #17
Harold Aptroot wrote:
"santosh" <sa*********@gmail.comwrote in message
news:g7**********@registered.motzarella.org...
>Harold Aptroot wrote:
>>"jt" <ka**********@gmail.comwrote in message
news:38**********************************@v1g2000 pra.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
es*****@ieee-dot-org.invalid
Aug 4 '08 #18
"Harold Aptroot" <ha************@gmail.comwrites:
"santosh" <sa*********@gmail.comwrote in message
news:g7**********@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) ks***@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"
Aug 4 '08 #19
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.
Aug 4 '08 #20
Harold Aptroot wrote:
"MisterE" <Mi*****@nimga.comwrote 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.
Aug 4 '08 #21
On Mon, 04 Aug 2008 17:42:31 -0400, CBFalconer wrote:
Harold Aptroot wrote:
>"MisterE" <Mi*****@nimga.comwrote 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.
Aug 4 '08 #22
CBFalconer <cb********@yahoo.comwrites:
Harold Aptroot wrote:
>"MisterE" <Mi*****@nimga.comwrote 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.
Aug 4 '08 #23
CBFalconer <cb********@yahoo.comwrites:
Harold Aptroot wrote:
>"MisterE" <Mi*****@nimga.comwrote 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) ks***@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"
Aug 5 '08 #24
In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:
>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
Aug 5 '08 #25
Keith Thompson wrote:
CBFalconer <cb********@yahoo.comwrites:
.... 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.
Aug 5 '08 #26
On 4 Aug, 23:25, Harald van D©¦k <true...@gmail.comwrote:
On Mon, 04 Aug 2008 17:42:31 -0400, CBFalconer wrote:
Harold Aptroot wrote:
"MisterE" <Mist...@nimga.comwrote 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.
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)
Aug 5 '08 #27
On 4 Aug, 22:30, CBFalconer <cbfalco...@yahoo.comwrote:
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
Aug 5 '08 #28
Nick Keighley wrote:
On 4 Aug, 22:30, CBFalconer <cbfalco...@yahoo.comwrote:
>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

Aug 5 '08 #29
Nick Keighley wrote:
On 4 Aug, 22:30, CBFalconer <cbfalco...@yahoo.comwrote:
>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.

Aug 5 '08 #30
Chris Dollin wrote:
Nick Keighley wrote:
>On 4 Aug, 22:30, CBFalconer <cbfalco...@yahoo.comwrote:
>>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.
Aug 5 '08 #31
"Nick Keighley" <ni******************@hotmail.comwrote in message
news:57**********************************@a1g2000h sb.googlegroups.com...
On 4 Aug, 23:25, Harald van D©¦k <true...@gmail.comwrote:
>On Mon, 04 Aug 2008 17:42:31 -0400, CBFalconer wrote:
Harold Aptroot wrote:
"MisterE" <Mist...@nimga.comwrote 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.
Aug 5 '08 #32

"jt" <ka**********@gmail.comwrote in message
news:38**********************************@v1g2000p ra.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

Aug 5 '08 #33
Harold Aptroot wrote:
"Nick Keighley" <ni******************@hotmail.comwrote in message
news:57**********************************@a1g2000h sb.googlegroups.com...
>On 4 Aug, 23:25, Harald van D?k <true...@gmail.comwrote:
>>On Mon, 04 Aug 2008 17:42:31 -0400, CBFalconer wrote:
Harold Aptroot wrote:
"MisterE" <Mist...@nimga.comwrote 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.

Aug 5 '08 #34
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
Aug 5 '08 #35
Bartc wrote:
>
"jt" <ka**********@gmail.comwrote in message
news:38**********************************@v1g2000p ra.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.

Aug 5 '08 #36
"santosh" <sa*********@gmail.comwrote in message
news:g7**********@registered.motzarella.org...
Harold Aptroot wrote:
>"Nick Keighley" <ni******************@hotmail.comwrote in message
news:57**********************************@a1g2000h sb.googlegroups.com...
>>On 4 Aug, 23:25, Harald van D?k <true...@gmail.comwrote:
On Mon, 04 Aug 2008 17:42:31 -0400, CBFalconer wrote:
Harold Aptroot wrote:
"MisterE" <Mist...@nimga.comwrote 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"

Aug 5 '08 #37
Harold Aptroot wrote:
"santosh" <sa*********@gmail.comwrote in message
news:g7**********@registered.motzarella.org...
>Harold Aptroot wrote:
>>>>"MisterE" <Mist...@nimga.comwrote 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.

Aug 5 '08 #38
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

Aug 5 '08 #39
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

Aug 5 '08 #40


"CBFalconer" <cb********@yahoo.comwrote in message
news:48***************@yahoo.com...
Harold Aptroot wrote:
>"MisterE" <Mi*****@nimga.comwrote 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

Aug 5 '08 #41
Harold Aptroot wrote:
"CBFalconer" <cb********@yahoo.comwrote 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.
Aug 5 '08 #42
CBFalconer <cb********@yahoo.comwrites:
Keith Thompson wrote:
>CBFalconer <cb********@yahoo.comwrites:
... 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) ks***@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"
Aug 5 '08 #43
Harold Aptroot wrote:
>

"CBFalconer" <cb********@yahoo.comwrote in message
news:48***************@yahoo.com...
>Harold Aptroot wrote:
>>"MisterE" <Mi*****@nimga.comwrote 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.

--
Er*********@sun.com
Aug 5 '08 #44
santosh <sa*********@gmail.comwrites:
Nick Keighley wrote:
>On 4 Aug, 22:30, CBFalconer <cbfalco...@yahoo.comwrote:
>>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) ks***@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"
Aug 5 '08 #45
Eric Sosman wrote:

<snip>

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

Aug 5 '08 #46
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
Aug 5 '08 #47
Richard Heathfield <rj*@see.sig.invalidwrites:
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?
Aug 5 '08 #48
In article <g7**********@registered.motzarella.org>,
Richard <rg****@gmail.comwrote:
>Richard Heathfield <rj*@see.sig.invalidwrites:
>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
Aug 5 '08 #49
ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:
In article <g7**********@registered.motzarella.org>,
Richard <rg****@gmail.comwrote:
>>Richard Heathfield <rj*@see.sig.invalidwrites:
>>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.
Aug 5 '08 #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...
14
by: Kevin Grigorenko | last post by:
Hello, I couldn't find an obvious answer to this in the FAQ. My basic question, is: Is there any difference in allocating on the heap versus the stack? If heap or stack implementation is not...
4
by: Chris Mabee | last post by:
Hello all, and Merry Christmas, I'm having a problem understanding an example of an array based implementation of a stack in a textbook of mine. The code in question is written below. The syntax...
4
by: anonymous | last post by:
Thanks your reply. The article I read is from www.hakin9.org/en/attachments/stackoverflow_en.pdf. And you're right. I don't know it very clearly. And that's why I want to understand it; for it's...
8
by: LedZep | last post by:
What up everyone, I have to write a program that uses a stack to determine whether a string is a palindrome (a string that is spelled identically backward and forward). The program has to...
4
by: alisaee | last post by:
plz check what i have made wrong what is requierd her is to creat class queue and class stack and run the push,pop operation . #include<iostream.h> #include<conio.h> #include<stdio.h> class...
16
by: sarathy | last post by:
Hi all, I need a few clarifications regarding memory allocaion in C++. I apologize for the lengthy explanation. 1. In C++, Objects are allocated in heap. What does heap refer to? Is it an area...
24
by: John | last post by:
I know this is a very fundamental question. I am still quite confused if the program call stack stack should always grows upwards from the bottom, or the opposite, or doesn't matter?? That means...
1
by: alfie27 | last post by:
I currently have a working program that is a stack that stores integers. Now i have to convert it to store strings instead of integers. I have been working on this for hours and just keep getting...
11
by: tom | last post by:
Hi! Im new to Python and doing exercise found from internet. It is supposed to evaluate expression given with postfix operator using Stack() class. class Stack: def __init__(self): self.items...
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
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: 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: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
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.