Doubt on Stack variables.

[deepak]

Hi In the following function how the memory 'll be allocated.

1) Will it allocate memory for all the char's together or allocate for
first char. then for int then for float and after
this only second char in the function gets memory.
2) If i declare variables where the size of al variables gone beyond
sizeof stack (assume it is 1000) what 'll
happen?

voud foo( int a, innt b)
{

char cb;
int ib;
float fc;
int ic;
char cc;

}

[Gordon Burditt]

>Hi In the following function how the memory 'll be allocated.

Standard C does not dictate how. It might be by purchase order
paid for with PayPal.

C does not define anything called a "stack". For this question,
it seems to refer to the place where auto variables are allocated.

>1) Will it allocate memory for all the char's together or allocate for
first char. then for int then for float and after
this only second char in the function gets memory.

It is not guaranteed that the variables will be allocated in reverse
order of the translation of the variable name into Pig Latin, or
any other particular order.

>2) If i declare variables where the size of al variables gone beyond
sizeof stack (assume it is 1000) what 'll
happen?

It probably won't be pretty. Expect whatever's beyond that point to
get trashed. Then expect a mess when it's used for its original purpose.

>voud foo( int a, innt b)

voud? innt? Are these typedefs for doubles?

>{

char cb;
int ib;
float fc;
int ic;
char cc;

}

[Keith Thompson]

"deepak" <de*********@gmail.comwrites:

Hi In the following function how the memory 'll be allocated.

1) Will it allocate memory for all the char's together or allocate for
first char. then for int then for float and after
this only second char in the function gets memory.
2) If i declare variables where the size of al variables gone beyond
sizeof stack (assume it is 1000) what 'll
happen?

voud foo( int a, innt b)
{

char cb;
int ib;
float fc;
int ic;
char cc;

}

The compiler can allocate the variables in any order it likes. If you
write good portable code, it won't matter.

The C standard doesn't specify a "stack" (the word doesn't even appear
in the standard). Most compilers do use a stack for the allocation of
local variables, but even so "sizeof stack" doesn't mean anything.

Memory is not infinite, so eventually a program can run out of space
to allocate local variables. The limit usually applies to the total
current "stack" allocation for all active functions, not to the space
for a single function. If that limit is exceeded (a "stack
overflow"), the behavior is undefined; usually this means that the
program terminates with an error message.

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

[Sourcerer]

"deepak" <de*********@gmail.comwrote in message
news:11**********************@q2g2000cwa.googlegro ups.com...

>
Hi In the following function how the memory 'll be allocated.

1) Will it allocate memory for all the char's together or allocate for
first char. then for int then for float and after
this only second char in the function gets memory.
2) If i declare variables where the size of al variables gone beyond
sizeof stack (assume it is 1000) what 'll
happen?

voud foo( int a, innt b)

I suppose this constitutes two typos? Is this correct?

void foo(int a, int b)

{

char cb;
int ib;
float fc;
int ic;
char cc;

}

Any order of allocation is possible.
If your variables have consumed all stack space and you still want more, you
might get an "out of stack space" or similar message, followed by the crash of
your program, although some systems might not even be as generous as to give you
the message, and won't crash only your program.

--
"It is easy in the world to live after the world's opinion; it easy in solitude
to live after our own; but the great man is he who in the midst of the crowd
keeps with perfect sweetness the independence of solitude."
Ralph Waldo Emerson, Self-reliance 1841
http://pinpoint.wordpress.com/

[David T. Ashley]

"deepak" <de*********@gmail.comwrote in message
news:11**********************@q2g2000cwa.googlegro ups.com...

>
1) Will it allocate memory for all the char's together or allocate for
first char. then for int then for float and after
this only second char in the function gets memory.

Generally, 'C' only guarantees that a given symbol (a varialble or an array)
is allocated contiguously. There are no guarantees about how different
symbols are allocated with respect to each other. One cannot make
assumptions about the address relationship between ib and ic, for example.

As other posters have pointed out, the notion of a "stack" does not appear
in the standards. This is probably true. In fact, some small processor
compilers have memory models where they don't use a stack. Instead, the
compiler analyzes the calling tree from top to bottom and puts automatics
into a static area of memory that is shared with all functions at the same
level of the calling tree. (This happens with the understanding that
recursion and corecursion are disallowed.) This is attractive in small
machines because instructions to reference memory with respect to the stack
pointer are very expensive, and one gets smaller code size by statically
allocating automatic variables.

2) If i declare variables where the size of al variables gone beyond
sizeof stack (assume it is 1000) what 'll
happen?

In a small machine (such as a microcontroller), bad things may happen (such
as rolling over the stack pointer with undefined behavior). But in a larger
machine (such as the x86 with a typical operating system),

a)The stack limits are hard to exceed, AND

b)The behavior is very reliable, such as program termination due to
exceeding stack allocation.

For a typical large machine, 1000 small variables or an array of 1000
elements on the stack in a single function would probably be tolerated. At
compilation, the processor has instructions to address memory in the stack
frame with very large offsets, and usually the only limit from the
compiler's point of view is whether it can choose the machine instructions
it wants/needs to get to the data. At runtime, typically the stack is
managed via the traditional virtual memory mechanisms. I doubt that a
practical program (one designed to do a computing job rather than to test
the stack limits) would run into these limits.

--
David T. Ashley (dt*@e3ft.com)
http://www.e3ft.com (Consulting Home Page)
http://www.dtashley.com (Personal Home Page)
http://gpl.e3ft.com (GPL Publications and Projects)

[santosh]

deepak wrote:

Hi In the following function how the memory 'll be allocated.

1) Will it allocate memory for all the char's together or allocate for
first char. then for int then for float and after this only second char
in the function gets memory.

It is implementation dependant.

2) If i declare variables where the size of al variables gone beyond
sizeof stack (assume it is 1000) what 'll happen?

Firstly the C standard neither mentions nor requires a 'stack', though
it's a common feature of most systems.

What'll happen when you run out of stack space. Again it's
implementation dependant, but in many cases it's likely to lead to the
termination of your program or to corruption of memory and a crash
later.

voud foo( int a, innt b)

void foo(int a, int b)

{

char cb;
int ib;
float fc;
int ic;
char cc;

It's good practise to include an explicit return even for function
returning void.

}

If you're going to include code, please take the time to correct
obvious typos.

[p_cricket_guy]

santosh wrote:

deepak wrote:

Hi In the following function how the memory 'll be allocated.

<-- snipped -->

>
It's good practise to include an explicit return even for function
returning void.

Is that just a coding style or are there any benefits?
Thanks,
p_c_g

>

}

If you're going to include code, please take the time to correct
obvious typos.

[David T. Ashley]

<p_***********@yahoo.co.inwrote in message
news:11*********************@51g2000cwl.googlegrou ps.com...

santosh wrote:

>deepak wrote:

Hi In the following function how the memory 'll be allocated.

<-- snipped -->

>>
It's good practise to include an explicit return even for function
returning void.

Is that just a coding style or are there any benefits?

I'm going to conjecture it is just style.

Every human being has a certain set of irrational things they do.

In my case, I CANNOT STAND return statements without parenthesis, so you
find code of mine that looks like this:

return(3);

when others would write:

return 3;

There is no rational reason for my bias. It may be that I learned FORTRAN
first, or there may be some other similar reason.

There absolutely is no rational reason to include "return" at the end of a
function that returns void.

--
David T. Ashley (dt*@e3ft.com)
http://www.e3ft.com (Consulting Home Page)
http://www.dtashley.com (Personal Home Page)
http://gpl.e3ft.com (GPL Publications and Projects)

[Richard Tobin]

In article <Gv******************************@giganews.com>,
David T. Ashley <dt*@e3ft.comwrote:

>There absolutely is no rational reason to include "return" at the end of a
function that returns void.

Sometimes it empahises (to a human reader) a parallel between case that
might otherwise be missed, or emphasies that the flow of control reaches
that point.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[soccertl]

deepak wrote:

2) If i declare variables where the size of al variables gone beyond
sizeof stack (assume it is 1000) what 'll
happen?

It depends on the memory model and compiler used. For example, in our
large memory model running on OS/2, all function calls allocated a
stack frame to put the auto variables into. If you exceeded the stack
size by calling many functions deep into your thread, your program
received an exception indicating you ran out of stack space. You could
specify what stack size you wanted but the default was 4k, which was
easily overrun in our huge program.

So, there is not difinitive answer but a good guess would be your
program would throw an exception.

[Keith Thompson]

"David T. Ashley" <dt*@e3ft.comwrites:

"deepak" <de*********@gmail.comwrote in message
news:11**********************@q2g2000cwa.googlegro ups.com...

>1) Will it allocate memory for all the char's together or allocate for
first char. then for int then for float and after
this only second char in the function gets memory.

Generally, 'C' only guarantees that a given symbol (a varialble or an array)
is allocated contiguously. There are no guarantees about how different
symbols are allocated with respect to each other. One cannot make
assumptions about the address relationship between ib and ic, for example.

As other posters have pointed out, the notion of a "stack" does not appear
in the standards. This is probably true. In fact, some small processor
compilers have memory models where they don't use a stack. Instead, the
compiler analyzes the calling tree from top to bottom and puts automatics
into a static area of memory that is shared with all functions at the same
level of the calling tree. (This happens with the understanding that
recursion and corecursion are disallowed.) This is attractive in small
machines because instructions to reference memory with respect to the stack
pointer are very expensive, and one gets smaller code size by statically
allocating automatic variables.

A conforming implementation must support recursion; it's not optional.
A compiler can allocate local (block-scope) variables statically *if*
it can prove that there will be no recursive calls to that function
(and it presumably will do so only if there's some advantage). A
compiler can have an option that forbids recursion, but it will be
non-conforming in that mode; it might nevertheless be useful.

Assuming support for recursion, an implementation *must* allocate
local variables in a stack-like fashion (last in first out). But the
term "stack", and particularly the phrase "the stack", usually refers
to a *contiguous* region of memory indexed by a "stack pointer" which
is typically a CPU register. The kind of "stack" is very common, but
it's no required by the standard. Someone here has mentioned an IBM
mainframe operating system in which the space for a called function is
allocated as if by calling malloc().

[...]

For a typical large machine, 1000 small variables or an array of
1000 elements on the stack in a single function would probably be
tolerated. At compilation, the processor has instructions to
address memory in the stack frame with very large offsets, and
usually the only limit from the compiler's point of view is whether
it can choose the machine instructions it wants/needs to get to the
data. At runtime, typically the stack is managed via the
traditional virtual memory mechanisms. I doubt that a practical
program (one designed to do a computing job rather than to test the
stack limits) would run into these limits.

A recursive program can easily exceed any finite stack size or other
memory limit, either due to a logical error or because it's asked to
process a large amount of input data. And multi-user operating
systems typically impose memory limits on each process that are much
smaller than the total amount of memory (virtual or otherwise)
available on the system.

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

[Peter Nilsson]

Keith Thompson wrote:

...
A conforming implementation must support recursion; it's not optional.

No, it's a QoI issue.

The implementation shall be able to translate and execute at least
one
program that contains at least one instance of every one of the
following
limits:
...
- 127 arguments in one function call

One function call does not recursion make.

--
Peter

[Peter Nilsson]

David T. Ashley wrote:

...
As other posters have pointed out, the notion of a "stack" does not
appear in the standards.

No, the word stack does not appear, but the LIFO nature of function
calling certainly does.

--
Peter

[Keith Thompson]

"Peter Nilsson" <ai***@acay.com.auwrites:

Keith Thompson wrote:

>...
A conforming implementation must support recursion; it's not optional.

No, it's a QoI issue.

The implementation shall be able to translate and execute at least
one program that contains at least one instance of every one of
the following limits:
...
- 127 arguments in one function call

One function call does not recursion make.

Well, yeah, but I think it stretches the point. C99 6.5.2.2p11 says:

Recursive function calls shall be permitted, both directly and
indirectly through any chain of other functions.

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