How to know that stack is growing upward/downward?

[Alex Fraser]

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

Alex

 

[Nick Keighley]

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

 

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

 

[Richard Tobin]

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

[/QUOTE]

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]

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]

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]

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]

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]

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

Are you serious?

-- Richard

 

[kal]

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]

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]

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]

Can one take the address of a REGISTER variable?

Does one possess an elementary C textbook?

 

[Jens.Toerring]

(e-mail address removed)-berlin.de wrote in message news:<[email protected]>...

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

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

 

[Dik T. Winter]

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

 

[Keith Thompson]

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

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]

(e-mail address removed)-berlin.de wrote in message


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>

 

[Alex Fraser]

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?

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]

What are the two possibilities?

[/QUOTE]

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