static, global variable memory allocation

[fdmfdmfdm]

This is an interview question and I gave out my answer here, could you
please check for me?

Q. What are the memory allocation for static variable in a function,
an automatic variable and global variable?

My answer: static variable in function and global variable are
allocated in head, and automatic variable is allocated in stack.

Right?

 

[jacob navia]

(e-mail address removed) a écrit :

This is an interview question and I gave out my answer here, could you
please check for me?

Q. What are the memory allocation for static variable in a function,
an automatic variable and global variable?

My answer: static variable in function and global variable are
allocated in head, and automatic variable is allocated in stack.

Right?

Maybe you mean "heap" not "head" ???

If that is the case, you are mostly right, it depends on the
implementation and OS running, etc.

A program has a fixed area with the initial data of the program.
This is not the heap in the traditional sense but just a RAM space
filled with tables, strings, double data, etc.

The heap is a variable area used to allocate space for data
dynamically during program execution. That data can be
local to a function, or be global. You are confusing the scope
of a variable, and the place where it is allocated, what is
not the same.

{
char *m = malloc(2678);
// use of m
free(m);
}

m is allocated from the heap, but it is local to that block
since it is freed before the block is finished. The varible
"m", of pointer type, is local to that block, and is active
only when that block is active.

Mostly, local variables are allocated from the stack, but some
people here say there are machines without stack that implement
C. I do not know, I have never seen one of those. In any
case in most systems, the stack exists and it is used to
allocate local variables.

 

[Ben Pfaff]

My answer: static variable in function and global variable are
allocated in head, and automatic variable is allocated in stack.

Many answers could possibly be right. This one is wrong.

 

[Richard Tobin]

This is an interview question and I gave out my answer here, could you
please check for me?

Q. What are the memory allocation for static variable in a function,
an automatic variable and global variable?

My answer: static variable in function and global variable are
allocated in head, and automatic variable is allocated in stack.

This is right for common implementations, but it doesn't have to work
like that. And auto variables are commonly stored in registers as
well as on the stack.

(I assume you mean "heap" rather than "head", though the idea of allocating
variables in the user's brain appeals.)

-- Richard

 

[Richard Heathfield]

jacob navia said:

{
char *m = malloc(2678);
// use of m
free(m);
}

m is allocated from the heap, but it is local to that block
since it is freed before the block is finished.

No, that's wrong. In fact, m is an auto object, and it has function
scope. The memory allocated by malloc (if any) is taken from the free
store, for which the term "heap" may or may not be applicable on any
particular platform. Note also that m is not freed. What is freed is
the memory (if any) that was allocated by malloc.

The varible
"m", of pointer type, is local to that block, and is active
only when that block is active.

Well, m only *exists* when that block is active.

Mostly, local variables are allocated from the stack, but some
people here say there are machines without stack that implement
C.
Right.

I do not know, I have never seen one of those. In any
case in most systems, the stack exists and it is used to
allocate local variables.

How do you know that "most systems" have a stack?

 

[jacob navia]

Richard Heathfield a écrit :

jacob navia said:




No, that's wrong. In fact, m is an auto object, and it has function
scope. The memory allocated by malloc (if any) is taken from the free
store, for which the term "heap" may or may not be applicable on any
particular platform. Note also that m is not freed. What is freed is
the memory (if any) that was allocated by malloc.

Yes, I should have said:
"the memory area returned by malloc, and assigned to m"
In the next sentence I explained "m", and I should have
make it clear.

How do you know that "most systems" have a stack?

Because there is a LONG list of very popular microprocessors,
from the Motorola to the x86, from the power pc to the 16 bit
Analog devices DSP, that all have a stack.

Since most modern microprocessors use some of those
processors, I would say that most systems have a stack.

A stack is a natural organization for building activation
records. Since C supports recursion, either the machine
has a stack or some behind the scenes software must implement
one.

 

[Flash Gordon]

This is an interview question and I gave out my answer here, could you
please check for me?

Q. What are the memory allocation for static variable in a function,
an automatic variable and global variable?

My answer: static variable in function and global variable are
allocated in head, and automatic variable is allocated in stack.

Right?

Firstly the C standard does not define where the variable are allocated
only how long they last and where their names are visible.

Secondly that could be a bit problematic on a ship where the head is the
place you go to relieve yourself. You would just have to keep your legs
crossed if someone is running a program with logs of globals and statics
filling up the head.

If, on the other hand, you meant heap, then it would be wrong for a lot
of common implementations, although it could certainly be implemented
that way. Equally it could be implemented by allocating enough space on
the stack (if there is one) at program startup for all the static and
global data, and this might make sense on some systems. Then there is
static const and "global" const data that on some systems will be
programmed in to ROM and on others in to RAM marked as read only in a
separate place from other static/global data. Also the machines without
a stack will obviously not allocate automatic variables on the stack,
although other implementations tend to.

In other words it depends entirely on the implementation but you are
wrong for all the implementations I know of.

 

[fdmfdmfdm]

(e-mail address removed) wrote, On 06/02/07 16:00:





Firstly the C standard does not define where the variable are allocated
only how long they last and where their names are visible.

Secondly that could be a bit problematic on a ship where the head is the
place you go to relieve yourself. You would just have to keep your legs
crossed if someone is running a program with logs of globals and statics
filling up the head.

If, on the other hand, you meant heap, then it would be wrong for a lot
of common implementations, although it could certainly be implemented
that way. Equally it could be implemented by allocating enough space on
the stack (if there is one) at program startup for all the static and
global data, and this might make sense on some systems. Then there is
static const and "global" const data that on some systems will be
programmed in to ROM and on others in to RAM marked as read only in a
separate place from other static/global data. Also the machines without
a stack will obviously not allocate automatic variables on the stack,
although other implementations tend to.

In other words it depends entirely on the implementation but you are
wrong for all the implementations I know of.

Well, I meant to say "heap". OK, for your opinion, if you were asked
by this question, you will say all these variables will be allocated
on stack? Is there a "correct" answer for this question?

 

[Richard Tobin]

In other words it depends entirely on the implementation but you are
wrong for all the implementations I know of.

I think you must be interpreting "heap" in a narrow sense then. On
many unix implementations for example, the memory returned by malloc()
follows on directly from the area in which static data is stored, and
it is not unreasonable to use the term "heap" to refer to that entire
area. Presumably that is what the original poster had in mind.

-- Richard

 

[Eric Sosman]

(e-mail address removed) wrote, On 06/02/07 16:00:

[...]

Well, I meant to say "heap". OK, for your opinion, if you were asked
by this question, you will say all these variables will be allocated
on stack? Is there a "correct" answer for this question?

One correct answer goes something like this: "The
implementation can allocate memory in any way it likes,
so long as the allocations satisfy the requirements of
the C language." In answering the obvious follow-up,
the phrases "static storage duration" and "automatic
storage duration" may be useful (pedantry: variables
don't use "dynamic storage duration").

<off-topic>

Is it my imagination, or has somebody unleashed a
flood of inane interview questions recently? Half the
newsgroups I follow are being submerged with postings a
lot like fdmfdmfdm's, posing questions of similar, er,
depth. Is there book with a title like "1001 Moronic
Interview Questions" in circulation?

And the bigger issue: If you faced and aced a string
of such questions in an interview and were offered the
job, would you take it? Or would you flee?

"It's not enough to keep the mind alive."
-- Peter Cook in "Beyond the Fringe"

</off-topic>

 

[Jack Klein]

Well, I meant to say "heap". OK, for your opinion, if you were asked
by this question, you will say all these variables will be allocated
on stack? Is there a "correct" answer for this question?

The correct answer is that there is no "correct" answer for the C
language itself. There might be a "correct" answer if they specified
a particular compiler generating an executable for a particular OS, or
even "common" compilers for "common" desktop operating systems.

There is actually no "correct" answer for where "global" objects are
located, since the concept does not actually exist in the C standard.
External linkage comes close to what most people commonly mean by that
term, but it is by no means the same thing as, for example, a global
variable in BASIC.

 

[Flash Gordon]

Richard Tobin wrote, On 06/02/07 17:36:

I think you must be interpreting "heap" in a narrow sense then.

Quite possible. This shows another problem in using terminology outside
the standard without making it clear what you are referring to ;-)

> On
many unix implementations for example, the memory returned by malloc()
follows on directly from the area in which static data is stored, and
it is not unreasonable to use the term "heap" to refer to that entire
area. Presumably that is what the original poster had in mind.

I was now specifically aware of that, to be hones I gave up caring
before I started programming on Unix, but given:
static const char var[]="Static array";
Would you expect var to be in that area you refer to as a heap or, as I
would hope, in a separate memory region that was set to read only?

Also, I thought that it was common for the static/global data that is
not const to be allocated in a bss (or similar) section that is defined
as being zeroed and that historically at least the section the heap (as
I would use the term) was allocated in would not since it did not need
zeroing. Of course, I accept that security considerations could have
made this academic.

In any case, note the weasel words "I know of" which can certainly be
interpreted to mean the systems I know the details of, and thus as I was
not aware of what you have said it was still accurate ;-)

 

[santosh]

This is an interview question and I gave out my answer here, could you
please check for me?

Q. What are the memory allocation for static variable in a function,
an automatic variable and global variable?

My answer: static variable in function and global variable are
allocated in head, and automatic variable is allocated in stack.

What a pointless interview question!

Well, I suppose you meant to say heap instead of head. The more proper
term is free store. There's really no one correct answer to such a
question, since C has been implemented on a very wide variety of
machines. The C standard doesn't specify where objects are allocated.
It specifies their scope and visibility and some other information.
Implementations are free to allocate objects however they wish, as
long as they respect these conditions.

 

[santosh]

Well, I meant to say "heap". OK, for your opinion, if you were asked
by this question, you will say all these variables will be allocated
on stack? Is there a "correct" answer for this question?

The correct answer is that it's implementation specific.

 

[Flash Gordon]

Please do not quote peoples signatures (the bit after the "-- " unless
you are commenting on them.

Well, I meant to say "heap". OK, for your opinion, if you were asked
by this question, you will say all these variables will be allocated
on stack? Is there a "correct" answer for this question?

There is no one correct answer since as I said it depends on the
implementation. So my answer would depend on what sort of job the
interview was for and my opinion of the interviewer. If Richard
Heathfield was interviewing my I might well say something like, "as the
C standard does not define where the variables are stored only the
lifetime and the visibility of the names it depends entirely on the
implementation and it is extremely rare that one needs to know unless
either writing the loader or defining a linker command script for an
embedded system. On typical stack based systems automatic variables will
be stored on a stack, although it may not be the same stack as is used
for return addresses. Static data may if it is also const be stored in
ROM or a RAM that is flagged as read only, non-const data will typically...

If I considered the interviewer to be less knowledgeable I might give a
simpler answer, and the answer might well depend on what targets the
company tended to be producing software for. If the target was a
TMS320C2x I might well mention register AR7 for instance, since that
processor has a HW stack that is only used for program return addresses,
and is only 7 deep IIRC, and conventionally AR7 is used to implement a
stack, although you could just as easily use AR1, AR2 ...

 

[Richard Heathfield]

santosh said:

What a pointless interview question!

Well, I suppose you meant to say heap instead of head. The more proper
term is free store.

So I have always been led to believe, but I can find no reference to
this term in C89 (I didn't check C99, but I certainly recall that "free
store" was the allegedly canonical term well before C99 was ratified).

Does anyone know why "free store" is given canonical status?

 

[Mark McIntyre]

Richard Heathfield a écrit :

Because there is a LONG list of very popular microprocessors,
from the Motorola

Just to point out that Motorola is a chip maker, not a CPU, and some
of their chips have no stack.

to the x86, from the power pc

ppc is an example of a Motorola chip (once upon a time...).

to the 16 bit Analog devices DSP, that all have a stack.

I guess by 'most' in this case we mean "largest number of shipped
physical units". I'd probably agree on that basis. It is worth
stressing however, and I'm aware you mentioned in your original post,
that a stack is not required or expected by C.


--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Mark McIntyre]

santosh said:



So I have always been led to believe, but I can find no reference to
this term in C89 (I didn't check C99, but I certainly recall that "free
store" was the allegedly canonical term well before C99 was ratified).

Heap, stack and free store are not mentioned anywhere in the PDF od
C99.

Does anyone know why "free store" is given canonical status?

Wikipedia consider heap and free store synonyms. Meanwhile Herb Sutter
specifically differentiates between them on the Guru of the Week
website, by saying that malloc uses one, and new uses the other. Hm!

My guess is that free store was invented to differentiate from "heap"
as in a structured tree.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Eric Sosman]

Richard Heathfield wrote On 02/06/07 14:03,:

santosh said:




So I have always been led to believe, but I can find no reference to
this term in C89 (I didn't check C99, but I certainly recall that "free
store" was the allegedly canonical term well before C99 was ratified).

Does anyone know why "free store" is given canonical status?

I've got the opposite question: Does anyone know why
"heap" has come to mean just a big bucket of bytes, while
once upon a time it meant a specific kind of binary tree
(c.f. Heapsort)?

 

[Ben Pfaff]

I've got the opposite question: Does anyone know why
"heap" has come to mean just a big bucket of bytes, while
once upon a time it meant a specific kind of binary tree
(c.f. Heapsort)?

The plain English word "heap" is just a pile, so the word heap is
more suggestive for a big bucket of bytes than for a carefully
organized data structure, in my opinion.