Short question about automatic and dynamic variables and C standard

[MI_FM]

We all know local (automatic) variables are allocated using the stack,
and dynamic variables are allocated using the heap, but, does the
standard specify this, or it never say "stack" ad "heap"?

Thanx

 

[Seebs]

We all know local (automatic) variables are allocated using the stack,
and dynamic variables are allocated using the heap, but, does the
standard specify this, or it never say "stack" ad "heap"?

Excellent; 8.9/10.

But, it's Friday, and I'm *still* waiting for a compile, so I'm just gonna
answer anyway. If you're trolling, good work. If you're not, boy does
your timing suck.

We don't know this, because it's not true. The standard never refers to
either the stack or the heap. Many implementations don't have either.
Furthermore, it's not necessarily true that local variables are "allocated"
to memory AT ALL -- it is quite common for local variables to end up
living entirely in a scratch register and never being allocated to storage
at all.

The standard specifies three types of storage: Static storage (fixed location
from program start to program termination), automatic storage (allocated at or
before entry into a block or reaching a declaration, deallocated at some point
at or after exiting the block), and allocated storage (allocated through
functions such as malloc, deallocated through functions such as free).

Finally, there's no such thing as a "dynamic variable". Variables have to
be static or automatic. However, some static or automatic variables have
pointer types, and may be used to store the address of a region of allocated
storage.

As a nice concrete example, on an implementation I know rather better than
I really ever wanted to, when you allocate memory, you may get a chunk of
memory from a region of space set aside for memory allocation functions, which
is grown as needed when memory is allocated. Or... You might get a chunk of
memory which is created by requesting a dedicated block of storage from
the operating system, which block is not necessarily contiguous with that
main pool, and which will be returned to the operating system upon free.
There is a structure somewhat similar to what you call "the heap", but it's
quite possible to write programs in which you allocate a great deal of
memory using malloc, but no address returned by malloc is ever in the range
of addresses containing the "heap".

Meanwhile, non-static local variables may or may not ever be allocated to
memory. I think that, in general, it does use the stack for them, but
I believe some systems implement VLAs using a hidden pointer which uses
the standard dynamic allocation routines to allocate space, and which is
then freed upon exit from the function; certainly, such an implementation
was considered during discussion of the VLA feature.

-s

 

[MI_FM]

Excellent; 8.9/10.

But, it's Friday, and I'm *still* waiting for a compile, so I'm just gonna
answer anyway.  If you're trolling, good work.  If you're not, boy does
your timing suck.

We don't know this, because it's not true.  The standard never refers to
either the stack or the heap.  Many implementations don't have either.
Furthermore, it's not necessarily true that local variables are "allocated"
to memory AT ALL -- it is quite common for local variables to end up
living entirely in a scratch register and never being allocated to storage
at all.

The standard specifies three types of storage:  Static storage (fixed location
from program start to program termination), automatic storage (allocated at or
before entry into a block or reaching a declaration, deallocated at some point
at or after exiting the block), and allocated storage (allocated through
functions such as malloc, deallocated through functions such as free).

Finally, there's no such thing as a "dynamic variable".  Variables have to
be static or automatic.  However, some static or automatic variables have
pointer types, and may be used to store the address of a region of allocated
storage.

As a nice concrete example, on an implementation I know rather better than
I really ever wanted to, when you allocate memory, you may get a chunk of
memory from a region of space set aside for memory allocation functions, which
is grown as needed when memory is allocated.  Or... You might get a chunk of
memory which is created by requesting a dedicated block of storage from
the operating system, which block is not necessarily contiguous with that
main pool, and which will be returned to the operating system upon free.
There is a structure somewhat similar to what you call "the heap", but it's
quite possible to write programs in which you allocate a great deal of
memory using malloc, but no address returned by malloc is ever in the range
of addresses containing the "heap".

Meanwhile, non-static local variables may or may not ever be allocated to
memory.  I think that, in general, it does use the stack for them, but
I believe some systems implement VLAs using a hidden pointer which uses
the standard dynamic allocation routines to allocate space, and which is
then freed upon exit from the function; certainly, such an implementation
was considered during discussion of the VLA feature.

-s

Thanx for the exhaustive answer (and sorry for the wrong use of
therms, I wrote my question was, and was simply referring to variables
inside blocks of code/functions and to dinamically allocated memory).

I supposed the standard never talked about stack ad heap, and wanted a
confirmation, so thanx.

 

[Nobody]

It doesn't specify the underlying mechanism. If the program contains
recursive functions then a stack is necessary and I don't see a way around
it. However many compilers won't use a stack - on small systems it is quite
common for all variables to be as if they had a "static" keyword in front of
them.

That's overstating it slightly.

Compilers which allocate local variables at a fixed address typically
overlay the local variables of unrelated functions (i.e. functions which
don't have an ancestor-descendent relationship), so you can't rely upon
the contents being preserved between invocations.

Microchip's MCC18 (for PIC18) does this if you select "overlay" as the
default variable type (you can also declare specific variables with the
overlay storage class), but you can't use overlay variables in any
function which is called recursively, and you can't use them at all if you
use function pointers (as the compiler can't deduce the call graph at
compile time).