The result of comparing two pointers using is defined only if the two pointers point to elements within the same array or structure.

The standard says nothing about the direction of the stack or if a stack even exists.

And in answer to ‘dude’, you may be right – I’m not aware of how this kind of comparison fits against the C standard, though I can confirm it works as expected with GCC on at least a couple of platforms in practice.

I’ve been thinking about this recently, since I am prepping for upcoming interviews and re-exercising some old coding muscles.

Anyway, this is more or less the solution I came up with… but, unless I am mistaken… it’s not guaranteed to work by the C standard. The C standard (accoring to my sources, possibly dated) only guarantees comparisons of pointers by use of < will work “as expected” when comparing pointers inside the same array.

There are no guarantees that it will work in the way it is being used to solve this problem.

Have recent standards provided guarantees what happens when arbitrary pointers are compared?

http://en.wikipedia.org/wiki/Stack_buffer_overflow#Stacks_that_grow_up

Stacks that grow up

Within the topic of stack buffer overflows an often discussed but rarely seen architecture is one in which the stack grows in the opposite direction. This change in architecture is frequently suggested as a solution to the stack buffer overflow problem because any overflow of a stack buffer that occurs within the same stack frame can not overwrite the return pointer. Further investigation of this claimed protection finds it to be a naïve solution at best. Any overflow that occurs in a buffer from a previous stack frame will still overwrite a return pointer and allow for malicious exploitation of the bug. For instance, in the example above, the return pointer for foo will not be overwritten because the overflow actually occurs within the stack frame for strcpy. However, because the buffer that overflows during the call to strcpy resides in a previous stack frame, the return pointer for strcpy will have a numerically higher memory address than the buffer. This means that instead of the return pointer for foo being overwritten, the return pointer for strcpy will be overwritten. At most this means that growing the stack in the opposite direction will change some details of how stack buffer overflows are exploitable, but it will not reduce significantly in the number of exploitable bugs.

Can you share your views for this hot discussion w.r.t “direction of stack growth” -

http://groups.google.co.in/group/comp.arch.embedded/browse_thread/thread/1243efba95ebc0/9aaf2f6c899007a9?hl=en&amp;

snapshot of the query :
Why some processors have stack growing downwards and others have stack growing upwards ?
Any advantages/disadvantages w.r.t both these designs. Which is the best model ?
I serached the internet, but i did not find a good link that explains these stuffs in detail.

Thx in advans,
Karthik Balaguru

What are the security advantages of doing(stack growth) it up ? Can you give me a clear link ?
I think, that link did not have any details about the advantages of doing it Up.

I find that in the wikipedia link provided in the above article, it is talking about stack overflow which would be present for implementations involving stack growth in downward direction.
That can happen for stack growing in upward direction also.
Even the crash can happen for implementations involving stack growth in both downward and upward direction.

But, there is no mention of specific disadvantage mentioned w.r.t Stack growing in upward direction.

I find these lines only in wikipedia w.r.t disadvantages . There is no mention of disadvantage w.r.t stack growing in downward direction ->

“A disadvantage of stack based memory allocation is that a thread’s stack size can be as small as a few dozen kilobytes. Allocating more memory on the stack than is available can result in a crash due to stack overflow. Another disadvantage is that the memory stored on the stack is automatically deallocated when the function that created it returns, and thus the function must copy the data if they should be available to other parts of the program after it returns. ”

Thx in advans,
Karthik Balaguru

I find that in the wikipedia link provided in the above article, it is talking about stack overflow which would be present for implementations involving stack growth in upward direction. Even the crash can happen for implementations involving stack growth in upward direction.

But, there is no mention of specific disadvantage mentioned w.r.t Stack growing in upward direction.

I find these lines only in wikipedia w.r.t disadvantages . There is no mention of disadvantage w.r.t stack growing in downward direction ->

“A disadvantage of stack based memory allocation is that a thread’s stack size can be as small as a few dozen kilobytes. Allocating more memory on the stack than is available can result in a crash due to stack overflow. Another disadvantage is that the memory stored on the stack is automatically deallocated when the function that created it returns, and thus the function must copy the data if they should be available to other parts of the program after it returns. ”

Thx,
Karthik Balaguru