Pushes and Pops to/from stack?

K

Kenneth Lantrip

In Ansi-C C99 or Standard C or in GCC...

Is there a way to push a value onto the stack and then later retrieve it
within the same function?

void foo(void) {
.
.
push my value here;
.
.
pop my value here;
.
.
}

Or is this only machine dependant and/or compiler dependant?
 
L

Lew Pitcher

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kenneth said:
In Ansi-C C99 or Standard C or in GCC...

Is there a way to push a value onto the stack and then later retrieve it
within the same function?

<zen>There is only push and pop. There is no stack</zen>

[snip]


- --

Lew Pitcher, IT Consultant, Enterprise Application Architecture
Enterprise Technology Solutions, TD Bank Financial Group

(Opinions expressed here are my own, not my employer's)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)

iD8DBQFBCmnWagVFX4UWr64RAofmAKCfSNgM0gax7v0LrcOPQiidtAH6rACg7Wvk
hxqzx3sSj/CQbQkS6Sx5wCM=
=I//f
-----END PGP SIGNATURE-----
 
E

Emmanuel Delahaye

Kenneth Lantrip wrote on 30/07/04 :
In Ansi-C C99 or Standard C or in GCC...

Is there a way to push a value onto the stack and then later retrieve it
within the same function?

void foo(void) {
.
.
push my value here;
.
.
pop my value here;
.
.
}

Or is this only machine dependant and/or compiler dependant?

No way in standard C, because the machine stack is not required by the
stabdard, but you can write your own stack system in standard C if you
are interested in. You need an index, an array an three functions, for
example:

typedef struct
{
size_t sp;
size_t size;
unsigned long *p;
}
stk_s;

int stk_init (stk_s *this, unsigned long *p, size_t size);
int stk_push (stk_s *this, unsigned long data);
int stk_pop (stk_s *this, unsigned long *p_data);

You also could have a full dynamic version:

stk_s *stk_create (size_t size);
void this stk_delete (stk_s *this);
int stk_push (stk_s *this, unsigned long data);
int stk_pop (stk_s *this, unsigned long *p_data);
 
J

Jens.Toerring

Kenneth Lantrip said:
In Ansi-C C99 or Standard C or in GCC...
Is there a way to push a value onto the stack and then later retrieve it
within the same function?
void foo(void) {
.
.
push my value here;
.
.
pop my value here;
.
.
}
Or is this only machine dependant and/or compiler dependant?

If such a thing exists then it's a compiler dependend extension,
neither C89 nor C99 do meantion the word "stack" at all. What
exactly do you need that for (unless you're messing around with
assembler code embedded in the C code - and then you can do your
pushing and poping from assembler anyway)?

Regards, Jens
 
E

Emmanuel Delahaye

(supersedes <[email protected]>)

Kenneth Lantrip wrote on 30/07/04 :
In Ansi-C C99 or Standard C or in GCC...

Is there a way to push a value onto the stack and then later retrieve it
within the same function?

void foo(void) {
.
.
push my value here;
.
.
pop my value here;
.
.
}

Or is this only machine dependant and/or compiler dependant?

No way in standard C, because the machine stack is not required by the
standard, but you can write your own stack system in standard C if you
are interested in. You need an index, an array an three functions, for
example:

typedef struct
{
size_t sp;
size_t size;
unsigned long *p;
}
stk_s;

int stk_init (stk_s *this, unsigned long *p, size_t size);
int stk_push (stk_s *this, unsigned long data);
int stk_pop (stk_s *this, unsigned long *p_data);

You also could have a full dynamic version:

stk_s *stk_create (size_t size);
void this stk_delete (stk_s *this);
int stk_push (stk_s *this, unsigned long data);
int stk_pop (stk_s *this, unsigned long *p_data);
 
S

Stefan Ram

Kenneth Lantrip said:
Is there a way to push a value onto the stack and then later retrieve it
within the same function?
void foo(void) {
.
.
push my value here;
.
.
pop my value here;
.
.
}

In ISO/IEC 9899:1999 (E) there is no "stack", but possibly you
are looking for:

void alpha( void )
{ /*
.
.
*/
{ int value = 7; /* "push" */
/*
.
.
*/
} /* "pop" */
/*
.
.
*/ }
 
J

Julian V. Noble

Kenneth said:
In Ansi-C C99 or Standard C or in GCC...

Is there a way to push a value onto the stack and then later retrieve it
within the same function?

void foo(void) {
.
.
push my value here;
.
.
pop my value here;
.
.
}

Or is this only machine dependant and/or compiler dependant?

Unlike Forth and related languages, C does not presuppose a stack. It
is perfectly feasible to write C compilers for machines that do not
support an intrinsic stack.

OTOH, many C's support inline assembler code. In such C's, executing on
machines with an intrinsic stack, you can easily implement what you
want.

However I would recommend if you do this, that when you exit a function
embodying direct stack manipulation, you restore the stack to its prior
state. Otherwise you risk misplacing data and/or crashing the system.

As someone has noted, it is perfectly feasible to implement a software
stack in C if you need such a data structure, and to define functions that
push/pop data to/from it. This would be by far the safest course. In
fact, it is one way to implement a recursive algorithm in a non-recursive
manner--e.g. QuickSort in Fortran 77.

--
Julian V. Noble
Professor Emeritus of Physics
(e-mail address removed)
^^^^^^^^^^^^^^^^^^
http://galileo.phys.virginia.edu/~jvn/

"For there was never yet philosopher that could endure the toothache
patiently." -- Wm. Shakespeare, Much Ado about Nothing. Act v. Sc. 1.
 
K

Kenneth Lantrip

Emmanuel said:
Kenneth Lantrip wrote on 30/07/04 :



No way in standard C, because the machine stack is not required by the
stabdard, but you can write your own stack system in standard C if you
are interested in. You need an index, an array an three functions, for
example:

typedef struct
{
size_t sp;
size_t size;
unsigned long *p;
}
stk_s;

int stk_init (stk_s *this, unsigned long *p, size_t size);
int stk_push (stk_s *this, unsigned long data);
int stk_pop (stk_s *this, unsigned long *p_data);

You also could have a full dynamic version:

stk_s *stk_create (size_t size);
void this stk_delete (stk_s *this);
int stk_push (stk_s *this, unsigned long data);
int stk_pop (stk_s *this, unsigned long *p_data);

Thanks, I see what you mean. Dunno why I didn't think of that!
And... I could have as many stacks as I wanted!
 
K

Kenneth Lantrip

neither C89 nor C99 do meantion the word "stack" at all. What
exactly do you need that for (unless you're messing around with
assembler code embedded in the C code - and then you can do your
pushing and poping from assembler anyway)?

Regards, Jens

Ah, I was pondering a new and improved way to return strings from a
called function. A safer way in a multi-threaded program.

Pretty much my only conclusion is:

Create the neccessary string space *before* you call the string
manipulating function. Send pointer of string to function instead of
string.

I dunno, it's hard to break the thinking patterns of "other" languages.

I'll get it sooner or later. :)

Kenneth
 
J

Jens.Toerring

Kenneth Lantrip said:
Ah, I was pondering a new and improved way to return strings from a
called function. A safer way in a multi-threaded program.
Pretty much my only conclusion is:
Create the neccessary string space *before* you call the string
manipulating function. Send pointer of string to function instead of
string.

Well, you can always have the function itself malloc() enough memory
for the string and then have it return a pointer to it. All you have
to keep in mind not to forget to free() that string when it's not
needed anymore. Getting everything thread-safe is, of course, quite a
bit more difficult and typically involves more than just questions of
how and where to allocate the memory (but since threads aren't part
of C you wil have to resort to non-portable solutions anyway).

Regards, Jens
 
J

Joe Knapka

Julian V. Noble said:
Unlike Forth and related languages, C does not presuppose a stack. It
is perfectly feasible to write C compilers for machines that do not
support an intrinsic stack.

In C, while there is no requirement for a stack as such, the standard
does implicitly require some kind of data structure equivalent to a
stack, because it explicitly requires that arbitrary nesting of
functions be supported. (Specifically, C99.6.5.2.2 #11: "Recursive
function calls shall be permitted, both directly and indirectly
through any chain of other functions.")

Although I suppose that only implies the existence of a stack in cases
where a (direct or indirect) recursive call actually occurs. Functions
known to be non-recursive could store their arguments in a
statically-allocated area. Hmm. Are there compilers that actually
do that, I wonder? It seems determining whether a function is indirectly
recursive could require a depressing amount of code analysis.

Cheers,

-- Joe
 
L

Lew Pitcher

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Joe said:
In C, while there is no requirement for a stack as such, the standard
does implicitly require some kind of data structure equivalent to a
stack, because it explicitly requires that arbitrary nesting of
functions be supported. (Specifically, C99.6.5.2.2 #11: "Recursive
function calls shall be permitted, both directly and indirectly
through any chain of other functions.")

Although I suppose that only implies the existence of a stack in cases
where a (direct or indirect) recursive call actually occurs. Functions
known to be non-recursive could store their arguments in a
statically-allocated area. Hmm. Are there compilers that actually
do that, I wonder? It seems determining whether a function is indirectly
recursive could require a depressing amount of code analysis.

The zOS (ie MVS) program linkage protocol requires a linked-list rather than a
stack. Such a linked-list of "save area"s can permit programs (functions) to
recursively call each other, if each "save area" is dynamically allocated (and
they /can/ be).

So, while the zOS program linkage protocol does not support a 'stack'
construct, it certainly supports the C99 requirement of recursive calls.

- --
Lew Pitcher

Master Codewright & JOAT-in-training | GPG public key available on request
Registered Linux User #112576 (http://counter.li.org/)
Slackware - Because I know what I'm doing.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBFquXagVFX4UWr64RAi+4AJkBqMB/6kEm9y/Z7bSscMpbmq0WLACg3/K1
SxLmrcYKNh64b+rYOt/RHQ4=
=bBtw
-----END PGP SIGNATURE-----
 
J

Joe Knapka

Lew Pitcher said:
Joe Knapka wrote:
[snip]
In C, while there is no requirement for a stack as such, the standard
does implicitly require some kind of data structure equivalent to a ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
stack, because it explicitly requires that arbitrary nesting of
functions be supported.
[snip]

The zOS (ie MVS) program linkage protocol requires a linked-list rather than a
stack. Such a linked-list of "save area"s can permit programs (functions) to
recursively call each other, if each "save area" is dynamically allocated (and
they /can/ be).

So, while the zOS program linkage protocol does not support a 'stack'
construct, it certainly supports the C99 requirement of recursive calls.

Thanks for the info. The Stackless Python folks use something similar
to implement general continuations, IIRC; anyway you have destroyed my
naive assumption that all C compilers handle function invocation the
same way :)
--
Lew Pitcher

Master Codewright & JOAT-in-training | GPG public key available on request
Registered Linux User #112576 (http://counter.li.org/)
Slackware - Because I know what I'm doing.

Nice sig. (BTW what's a "JOAT"?)

-- Joe (Slackware user since 1993)
 
L

Lew Pitcher

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Joe Knapka wrote:
[snip]
Thanks for the info.

You're welcome
The Stackless Python folks use something similar
to implement general continuations, IIRC; anyway you have destroyed my
naive assumption that all C compilers handle function invocation the
same way :)

I don't profess to know all the intracacies of compiler design, or even all
the rules of C, but I've done a little reading and a little programming, and
am glad to be able to pass some of my experience along.
Nice sig.

Thanks. I try to stay within reasonable bounds, but wanted to say a number of
things in it.
(BTW what's a "JOAT"?)

Jack Of All Trades (but, I guess, it should be "JoaT", not "JOAT") ;-)
-- Joe (Slackware user since 1993)


- --
Lew Pitcher

Master Codewright & JOAT-in-training | GPG public key available on request
Registered Linux User #112576 (http://counter.li.org/)
Slackware - Because I know what I'm doing.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBFt7IagVFX4UWr64RAgjOAJ9iUiB8eOTv28r4/Qcx7gLyF9DYDwCgjQ91
hpRn17vf0irbNlrf3gVvAwM=
=j9bj
-----END PGP SIGNATURE-----
 
M

Michael Wojcik

Thanks for the info. The Stackless Python folks use something similar
to implement general continuations, IIRC; anyway you have destroyed my
naive assumption that all C compilers handle function invocation the
same way :)

In one of the recent previous arguments over whether C must have a
stack here, I noted that a C implementation could use a list of
activation records for just that purpose - to implement continuations
as an extension.

Such an implementation could still be a conforming one, of course, as
long as programs did not make use of the continuations. Actually, I
suspect a conforming (though not s.c.) program could use the
implementation-provided extensions that *saved* continuations, as
long as it never *called* a continuation. Calling a continuation
would presumably render a program non-conforming because it would no
longer be following the flow-of-control rules used by the abstract
machine. (Note that's based entirely on idle speculation; I haven't
looked closely at the standard to see if it holds.)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,755
Messages
2,569,536
Members
45,014
Latest member
BiancaFix3

Latest Threads

Top