How to know that stack is growing upward/downward?

[Nitin Bhardwaj]

Hi all,

I wanted to know whether the stack in a C program is growing upwards
or
downwards.So I wrote a little code to see that.Please guide me as to
whether this code is correct in telling this ?

#include <stdio.h>
int main(void)
{
int * buf1 = malloc(10 * sizeof(int));
int *buf2 = malloc(10*sizeo f(int));

printf( buf1 ? buf2 ? "Downward" : "Backward") ;

return 0;
}

Thanks...

[Ariane van der Steldt]

In article <17************ **************@ posting.google. com>,
Nitin Bhardwaj wrote:

I wanted to know whether the stack in a C program is growing upwards
or
downwards.So I wrote a little code to see that.Please guide me as to
whether this code is correct in telling this ?

#include <stdio.h>
int main(void)
{
int * buf1 = malloc(10 * sizeof(int));
int *buf2 = malloc(10*sizeo f(int));

printf( buf1 ? buf2 ? "Downward" : "Backward") ;

return 0;
}

malloc et all don't allocate on the stack.
The direction of the stack is undefined in C. Refer to OS or hardware
specific documentation.

Ariane
--
We remember the song,
But not the hand that wrote it.
Nightwish -- Dead Boys Poem

[Richard Tobin]

In article <17************ **************@ posting.google. com>,
Nitin Bhardwaj <ni************ *@hotmail.com> wrote:

I wanted to know whether the stack in a C program is growing upwards
or downwards. So I wrote a little code to see that.Please guide me as to
whether this code is correct in telling this ? int * buf1 = malloc(10 * sizeof(int));
int *buf2 = malloc(10*sizeo f(int));

printf( buf1 ? buf2 ? "Downward" : "Backward") ;

This shows you the order of two objects allocated on the heap (which is
likely not to be consistent). You need to compare the addresses of local
variables, e.g.

char *stack_dir(void )
{
int a;
return stack_dir_helpe r(&a);
}

char *stack_dir_help er(int *a)
{
int *b;
return b < a ? "down" : "up";
}

This is of course not theoretically portable, but is likely to work on all
machines where the answer would be useful.

The only program I recall seeing that needed to know the stack
direction was Doug Gwyn's "portable alloca".

-- Richard

[Emmanuel Delahaye]

Nitin Bhardwaj wrote on 02/08/04 :

I wanted to know whether the stack in a C program is growing upwards
or
downwards.

There is no standard way to determine that. The answer is on your
compiler's documentation.

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html

"C is a sharp tool"

[pete]

Richard Tobin wrote:

char *stack_dir_help er(int *a)
{
int *b;
return b < a ? "down" : "up";
}

This is of course not theoretically portable,
"Undefined behavior" is the term usually used
to describe code like that in this newsgroup.
but is likely to work on all
machines where the answer would be useful.

I doubt it.
Your code attempts to compare the value of a,
which is a passed in argument,
against the value of b,
which is an uninitialized variable with an indeterminate value.

--
pete

[Richard Tobin]

In article <41***********@ mindspring.com> ,
pete <pf*****@mindsp ring.com> wrote:

char *stack_dir_help er(int *a)
{
int *b;
return b < a ? "down" : "up";
}

Your code attempts to compare the value of a,
which is a passed in argument, against the value of b,
which is an uninitialized variable with an indeterminate value.

Oops, of course that should be

int b;
return &b < a ? "down" : "up";

(I even compiled and ran the original to check for mistakes, but some
mistakes still produce the expected output!)

-- Richard

[Jens.Toerring]

Richard Tobin <ri*****@cogsci .ed.ac.uk> wrote:

In article <41***********@ mindspring.com> ,
pete <pf*****@mindsp ring.com> wrote:

char *stack_dir_help er(int *a)
{
int *b;
return b < a ? "down" : "up";
}

Your code attempts to compare the value of a,
which is a passed in argument, against the value of b,
which is an uninitialized variable with an indeterminate value.

Oops, of course that should be int b;
return &b < a ? "down" : "up"; (I even compiled and ran the original to check for mistakes, but some
mistakes still produce the expected output!)

The standard still tells you explicitely that you invoke undefined
behavior here, because 'a' and '&b' aren't pointers to members of
the same aggregate or union object (or one points to an array element
and the other points to the element directly after the same array).
Moreover, nothing forces the compiler to use a stack at all. So this
"solution" is about as safe as telling someone asking how to find
out the sequence in which function arguments are evaluated to use

int i = 0;
printf( "%d %d\n", ++i, ++i );

Regards, Jens
--
\ Jens Thoms Toerring ___ Je***********@p hysik.fu-berlin.de
\______________ ____________ http://www.toerring.de

[Richard Tobin]

In article <2n************ @uni-berlin.de>,
<Je***********@ physik.fu-berlin.de> wrote:

The standard still tells you explicitely that you invoke undefined
behavior here, because 'a' and '&b' aren't pointers to members of
the same aggregate or union object (or one points to an array element
and the other points to the element directly after the same array).
Moreover, nothing forces the compiler to use a stack at all.

We all know that. If you've got nothing useful to say, stay silent.

I imagine someone coming up to you in the street, and asking the way
to the post office. Instead of telling them, you point out that
there's no guarantee that there is a port office in this town, and
tell them that asking a stranger might lead to undefined behaviour.

There seems to be something about this newsgroup which produces an
almost religious unhelpfulness. It never used to be like that.

*If* your C implementation uses a stack - and if you say yours
doesn't, you're probably lying - then the code I gave will tell you
which way it goes. There are several reasons for wanting to know,
one of which I gave as an example, and another of which is just an
interest in how your machine works.

-- Richard

[Jens.Toerring]

Richard Tobin <ri*****@cogsci .ed.ac.uk> wrote:

In article <2n************ @uni-berlin.de>,
<Je***********@ physik.fu-berlin.de> wrote:

The standard still tells you explicitely that you invoke undefined
behavior here, because 'a' and '&b' aren't pointers to members of
the same aggregate or union object (or one points to an array element
and the other points to the element directly after the same array).
Moreover, nothing forces the compiler to use a stack at all.

We all know that. If you've got nothing useful to say, stay silent.
Are you sure? Ask the OP if he knows about that restriction. I for
one didn't know about such things at all when I learned C by myself
and only became aware of such problems by reading this newsgroup
_because_ people pointed them out again and again.
I imagine someone coming up to you in the street, and asking the way
to the post office. Instead of telling them, you point out that
there's no guarantee that there is a port office in this town, and
tell them that asking a stranger might lead to undefined behaviour.
Well, what you were telling the OP was: "Drive through that one-way
road to the post office." and not even mention that there's a the
big, fat sign that forbids to drive in that direction.
There seems to be something about this newsgroup which produces an
almost religious unhelpfulness. It never used to be like that.
Why is pointing out that the results of that operation can give
you completely wrong results unhelpful? The compiler is free to
produce code that exactly does what you expect it to do but it's
equally free to produce code that results in output that says the
stack is growing upwards while in reality its growing downward. And
it also is allowed to produce code that reformats the hard disk...

As far as I know this group it was standard to point out such
potential problems carefully. And I for one would like it to
stay it that way because otherwise whatever I read here would
have be taken with too much a grain of salt to be useful anymore.
*If* your C implementation uses a stack - and if you say yours
doesn't, you're probably lying - then the code I gave will tell you
which way it goes. There are several reasons for wanting to know,
one of which I gave as an example, and another of which is just an
interest in how your machine works.

Wanting to know is completely legitimate. But proposing methods to
find out that are not guaranteed to work without pointing out the
possible pitfalls isn't that helpful in my book.

Regards, Jens
--
\ Jens Thoms Toerring ___ Je***********@p hysik.fu-berlin.de
\______________ ____________ http://www.toerring.de

[Arthur J. O'Dwyer]

On Mon, 2 Aug 2004, Richard Tobin wrote:

<Je***********@ physik.fu-berlin.de> wrote:

The standard still tells you explicitely that you invoke undefined
behavior here, because 'a' and '&b' aren't pointers to members of
the same aggregate or union object (or one points to an array element
and the other points to the element directly after the same array).
Moreover, nothing forces the compiler to use a stack at all.

We all know that. If you've got nothing useful to say, stay silent.

I imagine someone coming up to you in the street, and asking the way
to the post office. Instead of telling them, you point out that
there's no guarantee that there is a [post] office in this town, and
tell them that asking a stranger might lead to undefined behaviour.

Well, that would be false --- in general, asking a stranger does
/not/ lead to undefined behavior. :) Jens' response, while less
helpful than it could have been,[1] was right on the money.

-Arthur

[1] - For example, Jens could have explicitly pointed out that
where your code had

char *stack_dir_help er(int *a)
{
int b;
return &b < a ? "down" : "up";
}
you almost certainly meant to write
char *stack_dir_help er(int a)
{
int b;
return &b < &a ? "down" : "up";
}

which will "correctly" return "down" on common unoptimized Wintel
implementations . I have no idea what it will produce for the average
'gcc -O2', in which it is common for both 'a' and 'b' to be stored
in 80x86 machine registers, let alone on a different architecture
entirely!