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*sizeof(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*sizeof(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*sizeof(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_helper(&a);
}

char *stack_dir_helper(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_helper(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*****@mindspring.com> wrote:

char *stack_dir_helper(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*****@mindspring.com> wrote:

char *stack_dir_helper(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***********@physik.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***********@physik.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_helper(int *a)
{
int b;
return &b < a ? "down" : "up";
}
you almost certainly meant to write
char *stack_dir_helper(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!

[Jens.Toerring]

Arthur J. O'Dwyer <aj*@nospam.andrew.cmu.edu> wrote:

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. [1] - For example, Jens could have explicitly pointed out that
where your code had

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

Not necessarily, if it works as advertised it will probably work with
both methods. In the first version 'a' is an automatic variable in an
earlier stack frame, so it should have a lower or higher address than
'b', depending on in which direction the stack grows (just with a
larger offset).
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!

gcc puts all variables that have their address taken into memory
and not keep them in registers (AFAIK even variables with storage
class register).
Regards, Jens
--
\ Jens Thoms Toerring ___ Je***********@physik.fu-berlin.de
\__________________________ http://www.toerring.de

[Christian Bau]

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

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

Anyway, there is very little consensus what the "top" and the "bottom"
of memory mean. While many people think that it is obvious, they don't
quite agree which of the two obvious possibilities they mean.

Much better to use the terms "left to right" or "right to left".

[Dik T. Winter]

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

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.

But Richard explicitly mentions in his first article on this subject that
his solution is not technically portable, so what more do you want? And
indeed, it will not port to all systems, but will port to many. (And I
have used a machine to which it would not port.)
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.

But he *did* mention it.
*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.

And here Richard is wrong... I know of at least one machine where for
each call to a routine a new memory segment was started. I do not know
whether comparison between addresses from different segments was useful,
or even allowed, but I would hesitate to port his solution to that
machine.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, [phone]
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[Chris Torek]

In article <ce***********@pc-news.cogsci.ed.ac.uk>
Richard Tobin <ri*****@cogsci.ed.ac.uk> writes:

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

Except, perhaps, where it may not. For instance, imagine an old
8086 compiler that uses the at-most-65536-byte segments (as quite
a few did) but changes the value in SS (the 'stack segment' pointer)
at the entry to each new function, so that each stack frame has
the full 64K available. Here the "sp" register in effect is always
zero. The result of &a is something like <xxxx:0> while &b is
something like <yyyy:0>. Equality comparisons (&a == &b, &a !=
&b) compare both segment-and-offset and say "not equal", but
relational comparisons (&a < &b) compare only offsets, giving the
wrong answer.

Of course, a real 8086 compiler would have to do extra work here
(because CALL and RET adjust SP, so every function entry would
have to recompute both SS and SP, and function exit would have to
undo this work) so this kind of implementation is unlikely on the
8086 -- but there might be other machines with similar oddities.
Since the C standard says that the effect of comparing pointers
that are not "pointing into" the same object (or one past the end
of that object) is undefined, an implementor is free -- at least
as far as C89 and C99 are concerned -- to do this sort of thing.

This does not mean you cannot experiment with whatever implementations
you have lying around, but it does mean you cannot extrapolate from
the results without some sort of additional information.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Richard Tobin]

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

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.

You obviously missed where I said:

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

-- Richard

[Jack Klein]

On 2 Aug 2004 22:01:00 GMT, ri*****@cogsci.ed.ac.uk (Richard Tobin)
wrote in comp.lang.c:

[snip]

*If* your C implementation uses a stack - and if you say yours
doesn't, you're probably lying

[snip]

It just so happens that I frequently use an excellent compiler for a
popular microcontroller, and automatic variables are _NEVER_ allocated
on a stack.

BTW, *plonk* for the accusation.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Dik T. Winter]

In article <Pi***********************************@unix43.andr ew.cmu.edu> "Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> writes:
....

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

....

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

Almost certainly *not*. While the changed code may work on most
implementations, it will *not* work if parameter frames are put on
a place quite different from the standard stack. "a" is the address
of the original on the stack, "&a" is the address of the place where
that address is put to be passed as parameter.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, [phone]
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[Alex Fraser]

"Christian Bau" <ch***********@cbau.freeserve.co.uk> wrote in message
news:ch*********************************@slb-newsm1.svr.pol.co.uk...
[snip]

Anyway, there is very little consensus what the "top" and the "bottom"
of memory mean. While many people think that it is obvious, they don't
quite agree which of the two obvious possibilities they mean.

What are the two possibilities?
Much better to use the terms "left to right" or "right to left".

How does that help?

Alex

[Richard Bos]

ni*************@hotmail.com (Nitin Bhardwaj) wrote:

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

Many people have been telling you that you can't do this, and that if
you assume a bog-standard OS you might be able to do this after all, and
that the results you might get are not necessarily meaningful, but
nobody has asked what I consider the most important question: _why_ do
you want to know this?
If it's simple curiosity, well and good, but if you think you really
need to know this in order to write good C, you are most likely better
off not knowing. Relying on system-dependent details like this is a
great way to make your code not only unportable, but unmaintainable and
probably more buggy than ordinary code.

Richard

[Christian Bau]

In article <2n************@uni-berlin.de>,
"Alex Fraser" <[e-mail]> wrote:

"Christian Bau" <ch***********@cbau.freeserve.co.uk> wrote in message
news:ch*********************************@slb-newsm1.svr.pol.co.uk...
[snip]

Anyway, there is very little consensus what the "top" and the "bottom"
of memory mean. While many people think that it is obvious, they don't
quite agree which of the two obvious possibilities they mean.

What are the two possibilities?

Can you think of _one_ possibility? If you say that a stack grows
"upward" or "downward" you must be able to say what that means, right?

Much better to use the terms "left to right" or "right to left".

How does that help?

[Alex Fraser]

"Christian Bau" <ch***********@cbau.freeserve.co.uk> wrote in message
news:ch*********************************@slb-newsm1.svr.pol.co.uk...

In article <2n************@uni-berlin.de>,
"Alex Fraser" <[e-mail]> wrote:

"Christian Bau" <ch***********@cbau.freeserve.co.uk> wrote in message
news:ch*********************************@slb-newsm1.svr.pol.co.uk...
[snip]

Anyway, there is very little consensus what the "top" and the
"bottom" of memory mean. While many people think that it is obvious,
they don't quite agree which of the two obvious possibilities they
mean.

What are the two possibilities?

Can you think of _one_ possibility?

Of course. I've only ever seen one; to me there is only _one_ "obvious"
possibility. Therefore your claims that there are two, and that "there is
very little consensus" are surprising to me.

Perhaps I should written instead, "Please elaborate."

Much better to use the terms "left to right" or "right to left".

How does that help?

Alex

[Nick Keighley]

ni*************@hotmail.com (Nitin Bhardwaj) wrote in message news:<17**************************@posting.google. com>...

I wanted to know whether the stack in a C program is growing upwards
or downwards.
why?
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*sizeof(int));

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

return 0;
}

pippo.c: In function `main':
pippo.c:4: warning: implicit declaration of function `malloc'
pippo.c:4: warning: initialization makes pointer from integer without a cast
pippo.c:5: warning: initialization makes pointer from integer without a cast
pippo.c:7: parse error before ')' token
--
Nick Keighley

"Resistance is futile. Read the C-faq."
-- James Hu (c.l.c.)

[pete]

Dik T. Winter wrote:

But Richard explicitly mentions in his first article
on this subject that
his solution is not technically portable, so what more do you want?

An explanation that malloced memory,
which is what OP's code was attempting to investigate,
does not lend itself well to being modeled as a stack
of contiguous memory which grows and shrinks.

Automatic memory lends itself nicely to implementation as a stack,
because it's : last created equals first destroyed.
Malloced memory isn't like that.
Any part of it, can be freed any time.
Calls to malloc may allocate higher addresses one time
and lower addresses another time.

--
pete

[Richard Tobin]

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

But Richard explicitly mentions in his first article
on this subject that
his solution is not technically portable, so what more do you want?

An explanation that malloced memory,
which is what OP's code was attempting to investigate,
does not lend itself well to being modeled as a stack
of contiguous memory which grows and shrinks.

The OP said he wanted to know which way the stack grew, and asked
whether his program using malloc() would answer that. The natural
interpretation is that his program was only investigating malloc()ed
memory by mistake.

I pointed out the error by saying:

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

If you wanted to elaborate on this, you could have done so directly
instead of complaining that I didn't.

-- Richard

[Kenny McCormack]

In article <I1********@cwi.nl>, Dik T. Winter <Di********@cwi.nl> wrote:

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

....

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

And here Richard is wrong... I know of at least one machine where for

Um, do you not understand the difference between the words (and the
meanings of these words) "probably" and "definitely"?

Richard is not wrong. You are *probably* lying. But not definitely so.

[Kenny McCormack]

In article <ce***********@pc-news.cogsci.ed.ac.uk>,
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.

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.

It has been this way for as long as I've been aware of this ng (over
a decade)
*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.

Come on - we all know the reason they post these questions. Virus/spam
writing.

[Kenny McCormack]

In article <41***************@news.individual.net>,
Richard Bos <rl*@hoekstra-uitgeverij.nl> wrote:

ni*************@hotmail.com (Nitin Bhardwaj) wrote:

I wanted to know whether the stack in a C program is growing upwards
or downwards.
Many people have been telling you that you can't do this, and that if
you assume a bog-standard OS you might be able to do this after all, and

Yes. It is all about writing viruses for Windows. I thought we all
understood that.
that the results you might get are not necessarily meaningful, but nobody
has asked what I consider the most important question: _why_ do you want
to know this? If it's simple curiosity, well and good, but if you think
you really need to know this in order to write good C, you are most likely
better off not knowing. Relying on system-dependent details like this is
a great way to make your code not only unportable, but unmaintainable and
probably more buggy than ordinary code.

See above.

[Richard Tobin]

In article <ce**********@yin.interaccess.com>,
Kenny McCormack <ga*****@interaccess.com> wrote:

Richard is not wrong. You are *probably* lying. But not definitely so.

I'm sure Dik is not lying. But the "you" was intended in its common
sense of "one", not addressed to a specific person.

-- Richard

[Richard Tobin]

In article <ce**********@yin.interaccess.com>,
Kenny McCormack <ga*****@interaccess.com> wrote:

Come on - we all know the reason they post these questions. Virus/spam
writing.

Are you serious?

-- Richard

[kal]

Je***********@physik.fu-berlin.de wrote in message news:<2n************@uni-berlin.de>...

gcc puts all variables that have their address taken into memory
and not keep them in registers (AFAIK even variables with storage
class register).

Can one take the address of a REGISTER variable?

[Kenny McCormack]

In article <ce***********@pc-news.cogsci.ed.ac.uk>,
Richard Tobin <ri*****@cogsci.ed.ac.uk> wrote:

In article <ce**********@yin.interaccess.com>,
Kenny McCormack <ga*****@interaccess.com> wrote:

Richard is not wrong. You are *probably* lying. But not definitely so.

I'm sure Dik is not lying. But the "you" was intended in its common
sense of "one", not addressed to a specific person.

-- Richard

Exactly - and anyone who's been on the net for more than a month ought to
understand that.

Further:
One of the things they do on the net is to post counter-examples and act
like that disproves a statement of the form "most Xs are Y". m-w.com can
help them with the meaning of the word "most".

[Kenny McCormack]

In article <ce***********@pc-news.cogsci.ed.ac.uk>,
Richard Tobin <ri*****@cogsci.ed.ac.uk> wrote:

In article <ce**********@yin.interaccess.com>,
Kenny McCormack <ga*****@interaccess.com> wrote:

Come on - we all know the reason they post these questions. Virus/spam
writing.

Are you serious?

Yes. I've seen a lot of posts recently (recently, meaning within the last
few years) from what are obviously clueless newbies - in a way in which we
experienced netizens can clearly recognize - asking really technical (and,
in CLC terms, obviously platform specific - we all know what the target
platform is) questions like "How can I tell which way the stack goes" or "I
need to write a server in TCPIP that can handle 1000000000000 simultaneous
connections". Sometimes, they even say: "Here's some code:

0x10,0x97,0x1234, blah, blah, blah

What does it do?"

In case that reference isn't clear, this is a standard
virus technique - they send you an email with an attachment that consists
of a very long series of hex bytes, encoded in some sort of Microsoft virus
wrapper - like .HTA or a Word or Excel macro or any of the other brilliant
ideas being cooked up daily by Bill & his gang.

[Kenny McCormack]

In article <a5**************************@posting.google.com >,
kal <k_*****@yahoo.com> wrote:

Je***********@physik.fu-berlin.de wrote in message news:<2n************@uni-berlin.de>...

gcc puts all variables that have their address taken into memory
and not keep them in registers (AFAIK even variables with storage
class register).

Can one take the address of a REGISTER variable?

Does one possess an elementary C textbook?

[Jens.Toerring]

kal <k_*****@yahoo.com> wrote:

Je***********@physik.fu-berlin.de wrote in message news:<2n************@uni-berlin.de>...

gcc puts all variables that have their address taken into memory
and not keep them in registers (AFAIK even variables with storage
class register).

Can one take the address of a REGISTER variable?

One can't, obviously;-) But gcc seems to take the liberty of ignoring
the register storage class specifier in that case (to which it is
entitled anyway) and put the variable into memory instead (but it
issues a warning even in the default settings). That's what it seems
to do on a 80x86 processor at least and all this was meant as an aside
to satisfy Arthur's curiosity.
Regards, Jens
--
\ Jens Thoms Toerring ___ Je***********@physik.fu-berlin.de
\__________________________ http://www.toerring.de

[Jens.Toerring]

Dik T. Winter <Di********@cwi.nl> wrote:

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

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

But Richard explicitly mentions in his first article on this subject that
his solution is not technically portable, so what more do you want? And
indeed, it will not port to all systems, but will port to many. (And I
have used a machine to which it would not port.)

But for my feeling the phrase "not technically portable" is so vague
that it won't tell the OP much - and might even go unnoticed - unless
he (and possibly other people reading the thread) already knows what's
problematic with the method. Unless he does he might end up with the
impression that it's the one and correct way to do that, which it not
really is. And at least for me it has always been one of the important
things in this group that people are a bit pedantic because that's how
I have learned about a lot of mistakes one can make (and which I made
because I simply didn't know any better).

I definitely didn't want to piss off Richard - maybe I had a bad day
and the way I wrote that wasn't as sympathetic as I at least hope I
normally try to be and should apologize to Richard for that - I hope
he reads this and accepts my apologies.

Regards, Jens
--
\ Jens Thoms Toerring ___ Je***********@physik.fu-berlin.de
\__________________________ http://www.toerring.de

[Dik T. Winter]

In article <ce**********@yin.interaccess.com> ga*****@interaccess.com writes:

In article <ce***********@pc-news.cogsci.ed.ac.uk>,
Richard Tobin <ri*****@cogsci.ed.ac.uk> wrote:

In article <ce**********@yin.interaccess.com>,
Kenny McCormack <ga*****@interaccess.com> wrote:

Richard is not wrong. You are *probably* lying. But not definitely so.
I'm sure Dik is not lying. But the "you" was intended in its common
sense of "one", not addressed to a specific person.

Let's see if I still understand it all. Richard writes that if somebody
tells something that that somebody probably is lying. Merriam-Webster
tells me that "probably" has the meaning "insofar as seems reasonably
true, factual, or to be expected: without much doubt". (Yes, I know
m-w, thank you very much.) I counter by saying that it is quite
possible that what is said *is* true. When Richard had written
"possibly" rather than "propably" I would not have said that he was
wront.
Exactly - and anyone who's been on the net for more than a month ought to
understand that.
I think I am on the net a bit more than a month.
One of the things they do on the net is to post counter-examples and act
like that disproves a statement of the form "most Xs are Y". m-w.com can
help them with the meaning of the word "most".

Yup. But most articles stating that "most Xs are Y" imply that almost *all*
Xs are Y, and that there is no sensible counter-example. You should have
known that if you had read the net a bit longer than a month.

You should also be aware that there are people on Usenet for whom English
is not a native language...
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, [phone]
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[Keith Thompson]

"Alex Fraser" <[e-mail]> writes:

"Christian Bau" <ch***********@cbau.freeserve.co.uk> wrote in message
news:ch*********************************@slb-newsm1.svr.pol.co.uk...
[snip]

Anyway, there is very little consensus what the "top" and the "bottom"
of memory mean. While many people think that it is obvious, they don't
quite agree which of the two obvious possibilities they mean.

What are the two possibilities?

In a listing, it's most common to show low addresses at the top:

0000 ...
0001 ...
0002 ...
0003 ...

But this puts numerically higher addresses at a lower position in the
listing.

If you say the stack grows "upward", do you mean that it grows toward
the top of the listing, or toward numerically higher addresses?
Whichever one you mean, are you sure that someone else won't mean the
opposite?

Much better to use the terms "left to right" or "right to left".

How does that help?

0000 ... 0001 ... 0002 ... 0003 ...

Unless you're accustomed to a right-to-left language like Arabic or
Hebrew, you're not likely to put high addresses on the left.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Keith Thompson]

k_*****@yahoo.com (kal) writes:

Je***********@physik.fu-berlin.de wrote in message
news:<2n************@uni-berlin.de>...

gcc puts all variables that have their address taken into memory
and not keep them in registers (AFAIK even variables with storage
class register).

Can one take the address of a REGISTER variable?

<NITPICK>I'll assume you mean "register", not "REGISTER".</NITPICK>

No, you can't legally take the address of a register variable in C.

<OT>In C++, you can (note that gcc handles both C and C++).</OT>

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Alex Fraser]

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

In a listing, it's most common to show low addresses at the top:

0000 ...
0001 ...
0002 ...
0003 ...

But this puts numerically higher addresses at a lower position in the
listing.
FWIW, I have only ever seen stack direction illustrated against a memory
diagram, which I have only ever seen drawn with high addresses at the top.
If you say the stack grows "upward", do you mean that it grows toward
the top of the listing, or toward numerically higher addresses?
The listing is irrelevant to me (which I think explains my original post);
it's how the value of the stack pointer changes that defines the direction.
Whichever one you mean, are you sure that someone else won't mean the
opposite?

Hmm, I guess not. But I suspect the vast majority would mean as I described
above, don't you?

Much better to use the terms "left to right" or "right to left".

How does that help?

0000 ... 0001 ... 0002 ... 0003 ...

Unless you're accustomed to a right-to-left language like Arabic or
Hebrew, you're not likely to put high addresses on the left.

Right, that makes sense now.

Thanks,
Alex

[Richard Tobin]

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.org> wrote:

> Anyway, there is very little consensus what the "top" and the "bottom"
> of memory mean. While many people think that it is obvious, they don't
> quite agree which of the two obvious possibilities they mean.

What are the two possibilities?

In a listing, it's most common to show low addresses at the top:

I don't think there's much confusion in practice. When referring to
a diagram, one might use up and down to refer to directions on the
diagram, but in the absence of a diagram I think almost everyone would
agree that "up" means towards numerically greater addresses. Phrases
such as "low memory" and stacks "growing down from the top of memory"
are commonly used without ambiguity.

-- Richard

[Keith Thompson]

"Alex Fraser" <[e-mail]> writes:

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

In a listing, it's most common to show low addresses at the top:

0000 ...
0001 ...
0002 ...
0003 ...

But this puts numerically higher addresses at a lower position in the
listing.

FWIW, I have only ever seen stack direction illustrated against a memory
diagram, which I have only ever seen drawn with high addresses at the top.

If you say the stack grows "upward", do you mean that it grows toward
the top of the listing, or toward numerically higher addresses?

The listing is irrelevant to me (which I think explains my original post);
it's how the value of the stack pointer changes that defines the direction.

Whichever one you mean, are you sure that someone else won't mean the
opposite?

Hmm, I guess not. But I suspect the vast majority would mean as I described
above, don't you?

Perhaps; I honestly don't know. I remember being confused about it
many years ago; since then, I haven't given it much thought (I pretty
much stopped caring which way the stack grows).

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Richard Bos]

ga*****@yin.interaccess.com (Kenny McCormack) wrote:

In article <41***************@news.individual.net>,
Richard Bos <rl*@hoekstra-uitgeverij.nl> wrote:

ni*************@hotmail.com (Nitin Bhardwaj) wrote:

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

Many people have been telling you that you can't do this, and that if
you assume a bog-standard OS you might be able to do this after all, and

Yes. It is all about writing viruses for Windows. I thought we all
understood that.

Oh, bull. We understand nothing of the sort. There are quite legitimate,
even if in my opinion usually misguided, reasons for being interested in
the structure of the stack - for example, premature optimisation.

Richard