Global Variables : Where are they stored ?

Richard <rg****@gmail.comwrites:

santosh <sa*********@gmail.comwrites:
>In article
<d5**********************************@s36g2000prg .googlegroups.com>,
Kislay <ki***********@gmail.comwrote on Tuesday 27 Nov 2007 8:40 pm:

>>Which of the following is correct regarding the storage of global
variables :
1. Global variables exist in a memory area that exists from before the
first reference in a program until after the last reference .

The C standard says that file scope objects are created and
initialised

Whats all this "file scope" you are bringing into it?

"File scope" is a term defined by the C standard. "Global variable"
is not. It's likely that what the OP meant by "global variables" is
variables (objects) declared at file scope, which therefore have
static storage duration.

Since C separates the concepts of visibility and lifetime, the phrase
"global variables" could be potentially ambiguous. It's important to
be clear about just what we're talking about.

(No, I'm not saying that C doesn't have global variables, merely that
it doesn't use that particular term for them.)

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Nov 27 '07 #9

Kislay

#include<stdio.h>
int global_var ; // The Global Variable I am talking about
int main()
{
return 0;
}
Thank you all for the above posts but it still doesn't clear my
doubt . Where does a global variable , like the one declared in the
program , global_var gets stored , i.e. which part of memory ?

Nov 28 '07 #10

Kislay <ki***********@gmail.comwrites:

#include<stdio.h>
int global_var ; // The Global Variable I am talking about
int main()
{
return 0;
}
Thank you all for the above posts but it still doesn't clear my
doubt . Where does a global variable , like the one declared in the
program , global_var gets stored , i.e. which part of memory ?

As others have said, there's really no answer to your question in
terms of C; it can vary from one implementation to another.

Why do you want to know? What use do you intend to make of the
information?

If you want to know the address of global-var, the answer is
"&globalvar".

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Nov 28 '07 #11

Kislay

What I really wanted to know was where it is stored . But you guys
tell me that it is implementation specific . Actually this was asked
in a job interview . And as far as I know the interviewer did not
mention any platform .

Nov 28 '07 #12

Podi

On Nov 27, 11:05 pm, Kislay <kislaychan...@gmail.comwrote:

What I really wanted to know was where it is stored . But you guys
tell me that it is implementation specific . Actually this was asked
in a job interview . And as far as I know the interviewer did not
mention any platform .

Ah, I usually ask this question in job interviews. I have also been
asked many times in when I was looking for a job.

In my opinion, it is important for a systems software engineer (who
works on embedded or device driver software) to know the "general"
memory structure of a process image.

In general, it is safe to say the following since it is similar on
Unix, Linux, Windows, ...

char *a; // uninitialized data segment
char *b = "hello"; // b is in uninitialized data segment, b's value
"hello" is in constant data segment
static char c; // file scope, not visible from other files
char d[8] = "world"; // initialized data segment, array of 8 bytes,
initialized first 6
// char d[800]; will cause file size of executable to be increased
char e[8]; // uninitialized data segment
// char e[800]; will cause process to require more memory, but same
executable file size

// foo is in the code segment
void foo(char f) // f is copied onto stack
{
char g; // allocated from stack
static char h; // data segment, not on stack so the value is
"static"
char *i = malloc(8); // heap, potential memory leak

// It is also important to know the difference of b and d
d[0] = 'h'; // OK
b[0] = 'y'; // likely to get a segmentation fault
}

Nov 28 '07 #13

santosh

Kislay wrote:

What I really wanted to know was where it is stored .

The memory address that C knows about is given by applying the
address-of operator (&) to it.

But you guys tell me that it is implementation specific .

Yes. The details are very much platform specific. It depends on the
memory models supported by the processor, operating system and system
linker as well as the exact executable file format that you are
compiling to.

A good place to ask such a question might be <news:comp.lang.asm.x86>
(for an x86 tailored answer) or <news:comp.arch>.

There are too many architectures and too many variations of them for us
to give you a meaningful answer.

Actually this was asked in a job interview . And as far as I know the
interviewer did not mention any platform .

If he did not mention a platform he was probably looking for a very
general answer or an x86 specific answer.

Nov 28 '07 #14

Kislay wrote:

What I really wanted to know was where it is stored .

We understand that. The answer has been given!

>But you guys tell me that it is implementation specific .

Correct. That /is/ the answer. Obviously you were expecting to be told
the actual place - but consider how many children ask each year where
Santa Claus lives. The answer to that is broadly similar.

Actually this was asked in a job interview .

Thats fine - the correct answer is still "its implementation specific".....

Nov 29 '07 #15

Podi wrote:

On Nov 28, 11:54 am, Flash Gordon <s...@flash-gordon.me.ukwrote:

>>Ah, I usually ask this question in job interviews. I have also been
asked many times in when I was looking for a job.
If I was asked in an interview (and I've never been asked that in an
interview) I would take it as a probable point against the interviewer.

No offense, but you will not likely to pass our interview :)

No offense in return, but I'd probably turn down the job anyway.
Interviewers who ask daft or unanswerable questions don't do their
company any favours, unless they show a good understanding of why they
asked the question. In which case we'd probably both have a pretty fun
interview discussing the merits of various arcana.

Not in my group. Most of the people here have 10+ years on systems SW.

Well, you and Flash can play "mine is bigger than yours" but I'm voting
with Flash for now... :-)

>>In general, it is safe to say the following since it is similar on
Unix, Linux, Windows, ...
char *a; // uninitialized data segment
If it is at file scope, then only if something initialised the
uninitialized data segment.
a is not at file scope.

As written by yourself, it was at file scope.

>>static char c; // file scope, not visible from other files
Here you did not even attempt an answer.

Trivial, same memory area as a. The importance is file scope.

Huh? a and c both have file scope. However c has internal linkage, thats
the difference. Note that scope and linkage are not the same. See 6.2.1
and 6.2.2 of the Standard.

>>void foo(char f) // f is copied onto stack
Or on many implementations passed in a register.
Agree. However, a CPU only has a limited number of registers. It will
most likely be on a stack after some level of function calls.

On modern nonembedded processors, this is AFAIK pretty unlikely in fact.

Nov 29 '07 #16

Barry Schwarz

On Tue, 27 Nov 2007 16:50:17 +0100, Richard <rg****@gmail.comwrote:

>santosh <sa*********@gmail.comwrites:

>In article
<d5**********************************@s36g2000prg .googlegroups.com>,
Kislay <ki***********@gmail.comwrote on Tuesday 27 Nov 2007 8:40 pm:

>>Which of the following is correct regarding the storage of global
variables :
1. Global variables exist in a memory area that exists from before the
first reference in a program until after the last reference .

The C standard says that file scope objects are created and
initialised

Whats all this "file scope" you are bringing into it?

It is the correct terminology for what is called a global variable in
the vernacular.
Remove del for email

Nov 29 '07 #17

Philip Potter

Podi wrote:

On Nov 28, 11:54 am, Flash Gordon <s...@flash-gordon.me.ukwrote:

>>Ah, I usually ask this question in job interviews. I have also been
asked many times in when I was looking for a job.
If I was asked in an interview (and I've never been asked that in an
interview) I would take it as a probable point against the interviewer.

No offense, but you will not likely to pass our interview :)

The feeling's mutual :)

>>// foo is in the code segment
void foo(char f) // f is copied onto stack
Or on many implementations passed in a register.
Agree. However, a CPU only has a limited number of registers. It will
most likely be on a stack after some level of function calls.

Where did you get this idea? Functions "deeper" on the stack will have
saved their registers to their stack frame to make the registers
available to the function currently executing. It doesn't make sense to
use registers for long-term storage of data concerning functions which
aren't currently executing.

On the ARM (which is the processor I'm most familiar with), the usual
calling convention is that the first four arguments are passed in
registers r0-r3, and any function (even with less than four parameters)
can clobber these registers for its own purpose. The return value is
placed in register r0, and the return address in r14. Any function which
calls another function must save any values in these registers which it
would like to keep.

This doesn't apply when you have arguments or return values which are
bigger than the size of a register. I'm not sure what happens then.

Phil

Nov 29 '07 #18

Podi

On Nov 29, 11:52 am, Flash Gordon <s...@flash-gordon.me.ukwrote:

Mark McIntyre wrote, On 29/11/07 00:33:

>>In general, it is safe to say the following since it is similar on
Unix, Linux, Windows, ...
char *a; // uninitialized data segment
If it is at file scope, then only if something initialised the
uninitialized data segment.
a is not at file scope.

As written by yourself, it was at file scope.

Indeed. If it was not at file scope and I was asked where it was
normally stored (as opposed to the requirements of the C standard) I
would suggest a register or the stack depending on register usage and
the details of the processor. On several implementations I've worked
with it is up to the developer to specify what section the stack is in,
so it could be in a section called "fred" for all the difference it makes.

>>static char c; // file scope, not visible from other files
Here you did not even attempt an answer.

Trivial, same memory area as a. The importance is file scope.

Huh? a and c both have file scope. However c has internal linkage, thats
the difference. Note that scope and linkage are not the same. See 6.2.1
and 6.2.2 of the Standard.

Of course, if a is not at file scope (as now specified) they will be in
conceptually different areas.

Yes, linkage is right term. I was trying to say that one can access
a's memory from other files by "extern char a;" but not the case for
"c".

>

>>void foo(char f) // f is copied onto stack
Or on many implementations passed in a register.
Agree. However, a CPU only has a limited number of registers. It will
most likely be on a stack after some level of function calls.

On modern nonembedded processors, this is AFAIK pretty unlikely in fact.

In any case, just stating "on the stack" is incorrect because on a small
leaf function it is very likely to be wrong.

The point I am stressing is that we prefer people who know about the
memory locations for our sw, which runs on Windows (desktop and CE),
Linux (desktop and embedded), other OSes such as cell phones,
handhelds, etc.

We have many large data structures that are like.

typedef struct
{
double a;
long b;
long long c;
short d;
short e;
double f;
// ...
double z;

} Data;

// developers who "does not care" about process memory image are
likely to write functions like
void A(Data d)
{
// do something with d
}

void B(Data d)
{
A(d);
}

// Continues with functions C, D, ..., X, Y, Z
void Y(Data d)
{
X(d);
}

// After many levels, would d still be in registers in function A?
// Even so, there would be lots of memory got pushed to the stack
along the way.
void Z(Data d)
{
Y(d);
}

// developers who "does care" about process memory image will most
likely write functions like
void A(const Data* d)
{
// do something with d->whatever
}

void B(const Data* d)
{
A(d);
}

// ...
void Z(const Data* d)
{
Y(d);
}

Sure, one can write correct C programs without ever knowing this
"general concept" (stack, heap, data segment, etc.), but it is
important when the SW runs on systems with limited resources.

So this is the answer to why we ask this question in our interviews.

Nov 29 '07 #19

Podi wrote, On 29/11/07 22:03:

On Nov 29, 11:52 am, Flash Gordon <s...@flash-gordon.me.ukwrote:
>Mark McIntyre wrote, On 29/11/07 00:33:

>>>>>In general, it is safe to say the following since it is similar on
>Unix, Linux, Windows, ...
>char *a; // uninitialized data segment
If it is at file scope, then only if something initialised the
uninitialized data segment.
a is not at file scope.

<snip>

>>>>>static char c; // file scope, not visible from other files
Here you did not even attempt an answer.
Trivial, same memory area as a. The importance is file scope.
Huh? a and c both have file scope. However c has internal linkage, thats
the difference. Note that scope and linkage are not the same. See 6.2.1
and 6.2.2 of the Standard.
Of course, if a is not at file scope (as now specified) they will be in
conceptually different areas.

Yes, linkage is right term. I was trying to say that one can access
a's memory from other files by "extern char a;" but not the case for
"c".

Static or not only affects whether the name is visible and on many
systems will not affect where it is stored. A pointer can easily be
generated allowing code in another translation unit to access it.

>>>>>void foo(char f) // f is copied onto stack
Or on many implementations passed in a register.
Agree. However, a CPU only has a limited number of registers. It will
most likely be on a stack after some level of function calls.
On modern nonembedded processors, this is AFAIK pretty unlikely in fact.
In any case, just stating "on the stack" is incorrect because on a small
leaf function it is very likely to be wrong.

The point I am stressing is that we prefer people who know about the
memory locations for our sw, which runs on Windows (desktop and CE),
Linux (desktop and embedded), other OSes such as cell phones,
handhelds, etc.

Ah, you mean systems with lots (more than 8K) or RAM!

We have many large data structures that are like.

typedef struct
{
double a;

<snip>

// developers who "does not care" about process memory image are
likely to write functions like
void A(Data d)
{
// do something with d
}

<snip>

// After many levels, would d still be in registers in function A?
// Even so, there would be lots of memory got pushed to the stack
along the way.
void Z(Data d)
{
Y(d);
}

// developers who "does care" about process memory image will most
likely write functions like
void A(const Data* d)
{
// do something with d->whatever
}

<snip>

If that is your concern then ask a more directly related question, such
as "how would you ass a large structure to a function?" With a
supplementary question of "now discuss what size you would switch from
one method of passing to another?" Or you could show some problem code
and ask what the problems are with it.

Sure, one can write correct C programs without ever knowing this
"general concept" (stack, heap, data segment, etc.), but it is
important when the SW runs on systems with limited resources.

So this is the answer to why we ask this question in our interviews.

The problem with passing large structs can be understood perfectly well
in terms of the C model of static, automatic and allocated duration
together with knowing that C uses pass-by-value. It does not require any
knowledge of stacks, heaps. data segments etc.
--
Flash Gordon

Nov 29 '07 #20

jameskuyper

Podi wrote:
....

The point I am stressing is that we prefer people who know about the
memory locations for our sw, which runs on Windows (desktop and CE),
Linux (desktop and embedded), other OSes such as cell phones,
handhelds, etc.

We have many large data structures that are like.

typedef struct
{
double a;
long b;
long long c;
short d;
short e;
double f;
// ...
double z;

} Data;

// developers who "does not care" about process memory image are
likely to write functions like
void A(Data d)
{
// do something with d
}

void B(Data d)
{
A(d);
}

// Continues with functions C, D, ..., X, Y, Z
void Y(Data d)
{
X(d);
}

// After many levels, would d still be in registers in function A?
// Even so, there would be lots of memory got pushed to the stack
along the way.
void Z(Data d)
{
Y(d);
}

// developers who "does care" about process memory image will most
likely write functions like
void A(const Data* d)
{
// do something with d->whatever
}

void B(const Data* d)
{
A(d);
}

// ...
void Z(const Data* d)
{
Y(d);
}

You don't have to know where the data is stored to prefer the second
implementation over the first one. It's sufficient to know that a
separate copy of the entire structure is created by each function call
in the first implementation, while the second one only creates enough
extra room to store a copy of the pointer.

If you are using an implementation with only a limited amount of
memory, you are justifiably more paranoid about about the amount of
memory used, but paying attention to the precise details of the
location of the memory is appropriate only for code that is so
implementation-specific that it will never be used anywhere where such
details might be different.

That doesn't describe any program I'm currently responsible for,
though I'm sure it's true for many other programs.

Nov 29 '07 #21

Podi <ze*****@gmail.comwrites:
[...]

The point I am stressing is that we prefer people who know about the
memory locations for our sw, which runs on Windows (desktop and CE),
Linux (desktop and embedded), other OSes such as cell phones,
handhelds, etc.

We have many large data structures that are like.

typedef struct
{

[lots of members]

} Data;

// developers who "does not care" about process memory image are
likely to write functions like
void A(Data d)
{
// do something with d
}

void B(Data d)
{
A(d);
}

// Continues with functions C, D, ..., X, Y, Z
void Y(Data d)
{
X(d);
}

// After many levels, would d still be in registers in function A?
// Even so, there would be lots of memory got pushed to the stack
along the way.
void Z(Data d)
{
Y(d);
}

// developers who "does care" about process memory image will most
likely write functions like
void A(const Data* d)
{
// do something with d->whatever
}

void B(const Data* d)
{
A(d);
}

// ...
void Z(const Data* d)
{
Y(d);
}

Sure, one can write correct C programs without ever knowing this
"general concept" (stack, heap, data segment, etc.), but it is
important when the SW runs on systems with limited resources.

So this is the answer to why we ask this question in our interviews.

In the code you posted, passing large Data object by value will cause
a new copy of the same object to be created on each call. Passing
pointers to the Data objects gets rid of this overhead. This is true
based just on the semantics defined by standard C; knowing that the
pointer approach reduces memory usage doesn't require knowing *where*
the memory is going to be allocated. If parameters were all allocated
on the heap rather than on the stack (as they actually are in some
systems), or even scribbled in leather bound books, the issue would be
pretty much the same.

Sure, there are contexts where you care about where the memory is
allocated rather than just how much. For example, "heap" memory might
happen to be more plentiful than "stack" memory in a given
implementation, or ROM might cheaper than ROM. But those aren't
really C questions; they're questions about a particular environment,
and are likely to apply to programs written in any language for that
environment.

I don't suggest that questions about memory segments aren't important,
or that you shouldn't be asking about them in interviews, just that
such questions aren't really about C.

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Nov 30 '07 #22

Podi

On Nov 29, 2:34 pm, jameskuy...@verizon.net wrote:

You don't have to know where the data is stored to prefer the second
implementation over the first one. It's sufficient to know that a
separate copy of the entire structure is created by each function call
in the first implementation, while the second one only creates enough
extra room to store a copy of the pointer.

Maybe you and Flash are right, the exact memory location is
implementation-specific. However, from my interview experience, if I
described the "general" process memory image when I was asked, I'd
pass this particular question. As a matter of fact, I was asked the
exact question when I interviewed for my current position. My believe
is that, asking it in such a subtle manner is sort of on purpose.

Essentially, we are looking for systems SW developers who know a bit
more on the system level, than just on the language level. This
question is just one way to make an assessment.

Nov 30 '07 #23

Barry Schwarz

On Tue, 27 Nov 2007 23:50:36 -0800 (PST), Podi <ze*****@gmail.com>
wrote:

>On Nov 27, 11:05 pm, Kislay <kislaychan...@gmail.comwrote:
>What I really wanted to know was where it is stored . But you guys
tell me that it is implementation specific . Actually this was asked
in a job interview . And as far as I know the interviewer did not
mention any platform .

Ah, I usually ask this question in job interviews. I have also been
asked many times in when I was looking for a job.

In my opinion, it is important for a systems software engineer (who
works on embedded or device driver software) to know the "general"
memory structure of a process image.

In general, it is safe to say the following since it is similar on
Unix, Linux, Windows, ...

Do you mean that this depends only on the operating system and not on
the compiler? That every compiler for linux does it the same way?

>
char *a; // uninitialized data segment

Unfortunately my system doesn't have a data segment.

>char *b = "hello"; // b is in uninitialized data segment, b's value
"hello" is in constant data segment

So you claim there are at least three data segments (uninitialized,
constant, and initialized).

>static char c; // file scope, not visible from other files
char d[8] = "world"; // initialized data segment, array of 8 bytes,
initialized first 6

All eight characters of the array are initialized.

>// char d[800]; will cause file size of executable to be increased

You are assuming that the initialized array is stored as such in the
executable. It is quite possible that the array will be created just
like e below but the startup code that runs before main will
initialize it.

>char e[8]; // uninitialized data segment
// char e[800]; will cause process to require more memory, but same
executable file size

// foo is in the code segment

My system doesn't have a code segment either.

>void foo(char f) // f is copied onto stack

My system doesn't have a stack either. If it did, f would not be
copied onto it. f is the formal parameter of the function. What is
copied onto the stack (in those systems where it is relevant) is the
value of the actual argument.

>{
char g; // allocated from stack
static char h; // data segment, not on stack so the value is
"static"
char *i = malloc(8); // heap, potential memory leak

No heap either.

>
// It is also important to know the difference of b and d
d[0] = 'h'; // OK
b[0] = 'y'; // likely to get a segmentation fault

My system doesn't have segmentation faults either. (In this case, I
would get a protection exception.) The only thing you can say for
sure is that the statement invokes undefined behavior.

>}

If you want to give system specific advise, you would be better off in
a system specific newsgroup.
Remove del for email

Nov 30 '07 #24

Podi

On Nov 29, 4:13 pm, Keith Thompson <ks...@mib.orgwrote:

I don't suggest that questions about memory segments aren't important,
or that you shouldn't be asking about them in interviews, just that
such questions aren't really about C.

I agree, and thanks for all the corrections on my posts with my
limited knowledge on the C standard.

Since we deal with mostly Windows (desktop + many variants of CE) and
Linux (many variants of desktop + many variants of embedded Linux),
and our code happens to be in C and C++, we are looking for people who
are at least familiar with the concept of memory layout as described
in the following.

http://dirac.org/linux/gdb/02a-Memor..._The_Stack.php
http://blogs.msdn.com/sloh/archive/2...25/380475.aspx
Since we also deal with many compilers, some of which do not comply
with "the standard", we are (at least I am) slacking quite a bit on
the correct definition of C :)

At the end of the day, the answer "implementation-specific" to OP is
wise and correct, but it will unlikely satisfy the interviewer. The
expected answer is to describe the "general" memory layout of a
process, given the simple, yet subtle question asked in C. And never
heard of "stack/heap" is sort of a no-no :)

Cheers!

Nov 30 '07 #25

Richard Harter

On Thu, 29 Nov 2007 16:13:59 -0800, Keith Thompson
<ks***@mib.orgwrote:

>
I don't suggest that questions about memory segments aren't important,
or that you shouldn't be asking about them in interviews, just that
such questions aren't really about C.

Not, perhaps, in comp.lang.c. However they are on point if one
is talking about using C in the "real world".

Richard Harter, cr*@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
In the fields of Hell where the grass grows high
Are the graves of dreams allowed to die

Nov 30 '07 #26

Walter Roberson

In article <47***************@news.sbtc.net>,
Richard Harter <cr*@tiac.netwrote:

>On Thu, 29 Nov 2007 16:13:59 -0800, Keith Thompson
<ks***@mib.orgwrote:

>>I don't suggest that questions about memory segments aren't important,
or that you shouldn't be asking about them in interviews, just that
such questions aren't really about C.

>Not, perhaps, in comp.lang.c. However they are on point if one
is talking about using C in the "real world".

Only if in the "real world" the memory arrangement is unique to C
on that particular system. If all executables for that particular
system use the same memory arrangement, then the question is not
one about using *C* "in the real world", it is one about the system
architecture independant of C.

--
"I was very young in those days, but I was also rather dim."
-- Christopher Priest

Nov 30 '07 #27

santosh

Walter Roberson wrote:

In article <47***************@news.sbtc.net>,
Richard Harter <cr*@tiac.netwrote:
>>On Thu, 29 Nov 2007 16:13:59 -0800, Keith Thompson
<ks***@mib.orgwrote:

>>>I don't suggest that questions about memory segments aren't
important, or that you shouldn't be asking about them in interviews,
just that such questions aren't really about C.

>>Not, perhaps, in comp.lang.c. However they are on point if one
is talking about using C in the "real world".

Only if in the "real world" the memory arrangement is unique to C
on that particular system. If all executables for that particular
system use the same memory arrangement, then the question is not
one about using *C* "in the real world", it is one about the system
architecture independant of C.

I would expect system level C code like operating system kernels,
compilers, debuggers, linkers etc., to need to know about the memory
layout of their targets, but certainly plain, application programs
shouldn't need this low level knowledge. Part of the reason for using a
high level language like C in the first place is to turn over the
management of such details to the machine.

Nov 30 '07 #28

Podi <ze*****@gmail.comwrites:

On Nov 29, 4:13 pm, Keith Thompson <ks...@mib.orgwrote:
>I don't suggest that questions about memory segments aren't important,
or that you shouldn't be asking about them in interviews, just that
such questions aren't really about C.

I agree, and thanks for all the corrections on my posts with my
limited knowledge on the C standard.

Since we deal with mostly Windows (desktop + many variants of CE) and
Linux (many variants of desktop + many variants of embedded Linux),
and our code happens to be in C and C++, we are looking for people who
are at least familiar with the concept of memory layout as described
in the following.

http://dirac.org/linux/gdb/02a-Memor..._The_Stack.php
http://blogs.msdn.com/sloh/archive/2...25/380475.aspx

In other words, you're looking for knowledge of memory layout on
Windows and Linux systems. In the scope of systems that have, or can
have, C implementations, Windows and Linux are actually quite similar
to each other.

Since we also deal with many compilers, some of which do not comply
with "the standard", we are (at least I am) slacking quite a bit on
the correct definition of C :)

Really? Very few compilers (yet) fully implement the C99 standard,
but I thought that almost all current C compilers conform reasonably
well to C90, at least in some (possibly non-default) mode. Unless
you're using some very old systems, I'm surprised that you'd be using
non-conforming compilers.

At the end of the day, the answer "implementation-specific" to OP is
wise and correct, but it will unlikely satisfy the interviewer. The
expected answer is to describe the "general" memory layout of a
process, given the simple, yet subtle question asked in C. And never
heard of "stack/heap" is sort of a no-no :)

Sure, nothing wrong with that in the context you're concerned with.

But you might be surprised at how much useful work you can get done
without going beyond what's guaranteed by the C standard.

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Nov 30 '07 #29

santosh

Keith Thompson wrote:

Podi <ze*****@gmail.comwrites:

<snip>

>Since we also deal with many compilers, some of which do not comply
with "the standard", we are (at least I am) slacking quite a bit on
the correct definition of C :)

Really? Very few compilers (yet) fully implement the C99 standard,
but I thought that almost all current C compilers conform reasonably
well to C90, at least in some (possibly non-default) mode. Unless
you're using some very old systems, I'm surprised that you'd be using
non-conforming compilers.

Some posters have mentioned that some embedded systems have only
non-conforming compilers, even for C90, since the peculiar nature of
such systems mean that a compiler with "special extensions" is more
useful than one completely conforming to standard C.

<snip>

Nov 30 '07 #30

Richard Harter

On Fri, 30 Nov 2007 17:40:52 +0000 (UTC),
ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) wrote:

>In article <47***************@news.sbtc.net>,
Richard Harter <cr*@tiac.netwrote:
>>On Thu, 29 Nov 2007 16:13:59 -0800, Keith Thompson
<ks***@mib.orgwrote:

>>>I don't suggest that questions about memory segments aren't important,
or that you shouldn't be asking about them in interviews, just that
such questions aren't really about C.

>>Not, perhaps, in comp.lang.c. However they are on point if one
is talking about using C in the "real world".

Only if in the "real world" the memory arrangement is unique to C
on that particular system. If all executables for that particular
system use the same memory arrangement, then the question is not
one about using *C* "in the real world", it is one about the system
architecture independant of C.

I opine you're missing the point. If one is going to program
effectively, one should have a general understanding of how
computers work, how operating systems typically work, and the
various ways resources are allocated and managed. Without that
knowledge it is all too easy (particularly in C) to write code
that is horribly inefficient or even just plain doesn't work.
Richard Harter, cr*@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
In the fields of Hell where the grass grows high
Are the graves of dreams allowed to die

Nov 30 '07 #31

santosh <sa*********@gmail.comwrites:

Keith Thompson wrote:
>Podi <ze*****@gmail.comwrites:

<snip>

>>Since we also deal with many compilers, some of which do not comply
with "the standard", we are (at least I am) slacking quite a bit on
the correct definition of C :)

Really? Very few compilers (yet) fully implement the C99 standard,
but I thought that almost all current C compilers conform reasonably
well to C90, at least in some (possibly non-default) mode. Unless
you're using some very old systems, I'm surprised that you'd be using
non-conforming compilers.

Some posters have mentioned that some embedded systems have only
non-conforming compilers, even for C90, since the peculiar nature of
such systems mean that a compiler with "special extensions" is more
useful than one completely conforming to standard C.

Sure, but the previous poster was talking about Linux and Windows
systems.

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Nov 30 '07 #32

santosh

Keith Thompson wrote:

santosh <sa*********@gmail.comwrites:
>Keith Thompson wrote:
>>Podi <ze*****@gmail.comwrites:

<snip>

>>>Since we also deal with many compilers, some of which do not comply
with "the standard", we are (at least I am) slacking quite a bit on
the correct definition of C :)

Really? Very few compilers (yet) fully implement the C99 standard,
but I thought that almost all current C compilers conform reasonably
well to C90, at least in some (possibly non-default) mode. Unless
you're using some very old systems, I'm surprised that you'd be
using non-conforming compilers.

Some posters have mentioned that some embedded systems have only
non-conforming compilers, even for C90, since the peculiar nature of
such systems mean that a compiler with "special extensions" is more
useful than one completely conforming to standard C.

Sure, but the previous poster was talking about Linux and Windows
systems.

He also mentioned Windows CE and various versions of embedded Linux.
However these particular embedded targets should have fully C90
conformant compilers. Perhaps his firm also develops for more exotic
chips like DSPs and so on.

Nov 30 '07 #33

Podi wrote, On 30/11/07 07:22:

On Nov 29, 4:13 pm, Keith Thompson <ks...@mib.orgwrote:

>I don't suggest that questions about memory segments aren't important,
or that you shouldn't be asking about them in interviews, just that
such questions aren't really about C.

I agree, and thanks for all the corrections on my posts with my
limited knowledge on the C standard.

Since we deal with mostly Windows (desktop + many variants of CE) and
Linux (many variants of desktop + many variants of embedded Linux),
and our code happens to be in C and C++, we are looking for people who
are at least familiar with the concept of memory layout as described
in the following.

http://dirac.org/linux/gdb/02a-Memor..._The_Stack.php

Oh, I'm familiar with that general type of layout and have been for a
long time. I'm also familiar with a number of other memory layouts,
including having program and data in completely separate address spaces
(i.e. address 0x1000 is *both* an address in program space *and* an
address in data space, and the contents is completely different and
unrelated in the two address spaces), systems where the stack runs the
other way, systems without a heap where it has been arranged so that the
stack grows away from other data etc.

http://blogs.msdn.com/sloh/archive/2...25/380475.aspx

Anyone with any real knowledge will take under 5 minutes to learn that
variation, so I would put familiarity with it a long way down the list.

Since we also deal with many compilers, some of which do not comply
with "the standard", we are (at least I am) slacking quite a bit on
the correct definition of C :)

At the end of the day, the answer "implementation-specific" to OP is
wise and correct, but it will unlikely satisfy the interviewer. The

No, the correct best answer is to start off with what the C standard
gives and the fact that it is implementation dependant and then (if
required) go on to a few examples of typical arrangements including (and
starting with), if you know the expected target, the memory layout on
the expected target.

expected answer is to describe the "general" memory layout of a
process, given the simple, yet subtle question asked in C.

Depends who asked the question what the expected answer is. In any case,
if you are the interviewer and you want to know if someone knows about
memory layouts then ask *that* question rather than a different
question. Otherwise you will risk rejecting programmers for answering
the question you asked when they know the answer to the question you
should have asked as well.

And never
heard of "stack/heap" is sort of a no-no :)

No one has suggested claiming ignorance of stacks and heaps in an
interview. My main point is that to test the knowledge you want to test
you should be asking a different question.
--
Flash Gordon

Nov 30 '07 #34

Podi

On Nov 30, 11:45 am, c...@tiac.net (Richard Harter) wrote:

On Fri, 30 Nov 2007 17:40:52 +0000 (UTC),
I opine you're missing the point. If one is going to program
effectively, one should have a general understanding of how
computers work, how operating systems typically work, and the
various ways resources are allocated and managed. Without that
knowledge it is all too easy (particularly in C) to write code
that is horribly inefficient or even just plain doesn't work.

Thank you! That's my exact point. I have spent most of my time view
code (mostly others' and some mine) much more than writing. My
experience has been that whenever I come across some inefficient code
(similar to the big struct I posted), the original author would highly
unlikely know about the concept of memory layout, regardless of how
long he has been programming in C.

I still want to emphasize that the way the question being asked is
effective, at least in my group's opinion. Most people who have "been
there, done that" would likely know what the interview is "really"
asking. And we don't just ask the global variable question, so we are
pretty confident that we don't miss a real good candidate :-)

BTW, our SW is not just a plain application, well most of it *is*. It
is already quite large in footprint, CPU and memory usage. On top of
that, it is supposed to run in the background. However, we quite often
still need to develop system level stuff like device drivers for IO,
power management, timer, etc. on a large range of OSes/CPUs. So
experiences with endianess and alignment are also important. I
mentioned on somewhere else that I used to work with an architectural
level Java/C# programmer who never heard of big/little endian.

We don't mind if the candidate can recite the C standard, but we would
be more interested if s/he can write efficient and portable SW. We
don't want clever code, so that the *non-original-author* can debug
more easily. We don't want fancy language features so that we can make
all our compilers happy. Anyway, that's not the real hard job
requirement. It is just the way I think it should be.

Actually it is quite a fun job. If anyone is interested, information
is on www.broadcom.com, and look for job openings in San Jose or
Irvine, California.

One final thought, maybe there ought to be a newsgroup like
comp.programming.c for this type of discussions. In here, I kept
getting the impression that the language rules are more important than
the language usage. Often times, some novice person would ask an entry
level question, and got responses like "the standard x.y.z says..."
thrown on the face. I mean, what percentage of programmer are really
writing compilers?

Dec 1 '07 #35

Podi

On Nov 30, 11:45 am, c...@tiac.net (Richard Harter) wrote:

>
I opine you're missing the point. If one is going to program
effectively, one should have a general understanding of how
computers work, how operating systems typically work, and the
various ways resources are allocated and managed. Without that
knowledge it is all too easy (particularly in C) to write code
that is horribly inefficient or even just plain doesn't work.

Thank you! That's my exact point. I have spent most of my time
viewing
code (mostly others' and some mine) much more than writing. My
experience has been that whenever I come across some inefficient code
(similar to the big struct I posted), the original author would
highly
unlikely know about the concept of memory layout, regardless of how
long he has been programming in C.

I still want to emphasize that the way the question being asked is
effective, at least in my group's opinion, since we would have already
explained the nature of the project. No offense to anyone here. Most
people who have "been there, done that" would likely know what the
interviewer is "really" asking. And we don't just ask the global
variable question, so we are pretty confident that we don't miss a
real good candidate :-)
BTW, our SW is not just a plain application, well most of it *is*. It
is already quite large in footprint (lots of algorithms, state
machines...), CPU (lots of signal processing) and memory (lots of
data) usage. On top of that, it is supposed to run in the background.
However, we quite often still need to develop system level stuff like
device drivers for IO, power management, timer, etc. on a large range
of OSes/CPUs. So experiences with endianess and alignment are also
important. I mentioned on somewhere else that I used to work with an
architectural level Java/C# programmer who never heard of big/little
endian.
We don't mind if the candidate can recite the C standard, but we
would
be more interested if s/he can write efficient and portable SW. We
don't want clever code, so that the *non-original-author* can debug
more easily. We don't want fancy language features so that we can
make
all our compilers happy. BTW, that's not the real hard job
requirements. It is just the way I think it should be.

One clarification: I am not sure if any of the compilers we use are
actually non-conforming. But if we use fancy language features and one
customer has an older compiler, we might have to go back and patch up.

Actually it is quite a fun job. If anyone is interested, information
is on www.broadcom.com, and look for job openings in San Jose or
Irvine, California.

Dec 1 '07 #36

Some posters have mentioned that some embedded systems have only

non-conforming compilers,

I'm not sure thats necessarily accurate. The requirements for
freestanding implementations are a lot different.

Dec 1 '07 #37

Podi wrote:

On Nov 30, 11:45 am, c...@tiac.net (Richard Harter) wrote:

>I opine you're missing the point. If one is going to program
effectively, one should have a general understanding of how
computers work, how operating systems typically work, and the
various ways resources are allocated and managed. Without that
knowledge it is all too easy (particularly in C) to write code
that is horribly inefficient or even just plain doesn't work.

This is true, but not unique to C. It would therefore be a question for
comp.programming.

I still want to emphasize that the way the question being asked is
effective, at least in my group's opinion, since we would have already
explained the nature of the project. No offense to anyone here.

None taken. The point is, its not topical in CLC, where the 'under the
hood' details of how operating systems and hardware work are not in scope.

Dec 1 '07 #38

Mark McIntyre wrote, On 01/12/07 11:01:

>Some posters have mentioned that some embedded systems have only
non-conforming compilers,

I'm not sure thats necessarily accurate. The requirements for
freestanding implementations are a lot different.

Some posters have mentioned compilers with and 8-bit int type. I have no
experience of such systems myself, but I remember them being mentioned.
--
Flash Gordon

Dec 1 '07 #39

Podi wrote, On 01/12/07 06:39:

On Nov 30, 11:45 am, c...@tiac.net (Richard Harter) wrote:
>On Fri, 30 Nov 2007 17:40:52 +0000 (UTC),
I opine you're missing the point. If one is going to program
effectively, one should have a general understanding of how
computers work, how operating systems typically work, and the
various ways resources are allocated and managed. Without that
knowledge it is all too easy (particularly in C) to write code
that is horribly inefficient or even just plain doesn't work.

Thank you! That's my exact point. I have spent most of my time view
code (mostly others' and some mine) much more than writing. My
experience has been that whenever I come across some inefficient code
(similar to the big struct I posted), the original author would highly
unlikely know about the concept of memory layout, regardless of how
long he has been programming in C.

From my experience there is no causal relationship although there may
well be a correspondence. I've seen comparable efficiency bugs from
people who definitely *did* know the ins and outs of the memory model of
the target, I've also seen efficient code written by people who did not
know the memory layout of the target.

I still want to emphasize that the way the question being asked is
effective, at least in my group's opinion.

Ah, but do you know that the people who rejected you would not have been
good recruits, and would not have taken the job had you asked better
questions? Do you know that the people who failed to see what you were
getting at would have been bad, or have you just assumed this? I bet you
have not checked on the people you don't recruit to find out.

Most people who have "been
there, done that" would likely know what the interview is "really"
asking.

Some of the best programmers I have known can be very literal people, so
you are quite likely to get the question you asked answered and not the
question you wanted the answer to.

Also, I want my managers to ask me the questions they are interested in
getting answers to and explain their real problems. So if at an
interview you try to find out about my knowledge of one thing by asking
about something else that will suggest to me you are probably not
someone I want to work for.

And we don't just ask the global variable question, so we are
pretty confident that we don't miss a real good candidate :-)

You don't know that. You also don't know how many candidates just decide
that if you are going to ask stupid questions you are not worth it.

BTW, our SW is not just a plain application, well most of it *is*. It
is already quite large in footprint, CPU and memory usage. On top of
that, it is supposed to run in the background. However, we quite often
still need to develop system level stuff like device drivers for IO,
power management, timer, etc. on a large range of OSes/CPUs. So
experiences with endianess and alignment are also important.

So ask about those things in an interview.

I
mentioned on somewhere else that I used to work with an architectural
level Java/C# programmer who never heard of big/little endian.

So? In those languages you generally don't need to know such things. In
C sometimes you do.

We don't mind if the candidate can recite the C standard, but we would
be more interested if s/he can write efficient and portable SW.

Someone who knows what the standard guarantees is *more* likely to be
able to write portable SW. Efficiency is another matter and requires
asking different questions.

We
don't want clever code, so that the *non-original-author* can debug
more easily.

Most people here don't want to write code that is cleverer than required
most of the time because it is more work to write.

We don't want fancy language features so that we can make
all our compilers happy.

Most of the fancy language features are nothing to do with portability,
it is actually the simple language facilities such as sizeof, limits.h
and knowing what is undefined that allow you to keep all your compilers
happy.

Anyway, that's not the real hard job
requirement. It is just the way I think it should be.

I don't think people have been saying that knowing such stuff is a bad
thing, and I've certainly been saying that you are asking the wrong
questions to find out about peoples knowledge.

Actually it is quite a fun job. If anyone is interested, information
is on www.broadcom.com, and look for job openings in San Jose or
Irvine, California.

One final thought, maybe there ought to be a newsgroup like
comp.programming.c for this type of discussions.

There is a process for creating new groups if you want to give it a go.

In here, I kept
getting the impression that the language rules are more important than
the language usage. Often times, some novice person would ask an entry
level question, and got responses like "the standard x.y.z says..."
thrown on the face. I mean, what percentage of programmer are really
writing compilers?

There are exactly two groups of people who should really know what the
standard guarantees...

1) Those writing compilers
2) Those using compilers

People using compilers need to know so that they do not do things like
"printf("%d %d",i++,i++)" or any of the other things that might work
today but fail tomorrow. I don't say that newbies need to be able to
read the standard, but they need to be aware that there *is* a standard
and to gradually learn the language defined by the standard is.
--
Flash Gordon

Dec 1 '07 #40

James Kuyper

Flash Gordon wrote:

Mark McIntyre wrote, On 01/12/07 11:01:

>>Some posters have mentioned that some embedded systems have only
non-conforming compilers,

I'm not sure thats necessarily accurate. The requirements for
freestanding implementations are a lot different.

Some posters have mentioned compilers with and 8-bit int type. I have no
experience of such systems myself, but I remember them being mentioned.

That would not be conforming, not even under the more relaxed rules that
apply to freestanding implementations. I believe that it is, however, a
common non-conforming mode, in fact often the default mode, for
compilers for embedded systems.

Dec 1 '07 #41

Richard Harter

On Sat, 01 Dec 2007 11:08:28 +0000, Mark McIntyre
<ma**********@spamcop.netwrote:

>Podi wrote:
>On Nov 30, 11:45 am, c...@tiac.net (Richard Harter) wrote:

>>I opine you're missing the point. If one is going to program
effectively, one should have a general understanding of how
computers work, how operating systems typically work, and the
various ways resources are allocated and managed. Without that
knowledge it is all too easy (particularly in C) to write code
that is horribly inefficient or even just plain doesn't work.

This is true, but not unique to C. It would therefore be a question for
comp.programming.

You've dropped the context, which is that Podi uses such
questions in interviewing candidates for C programmers and
approves of them. The context is a discussion is about the
appropriateness of such questions in interviews.

>
>I still want to emphasize that the way the question being asked is
effective, at least in my group's opinion, since we would have already
explained the nature of the project. No offense to anyone here.

None taken. The point is, its not topical in CLC, where the 'under the
hood' details of how operating systems and hardware work are not in scope.

If it is not topical then neither are any of the lengthy replies.
Richard Harter, cr*@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
In the fields of Hell where the grass grows high
Are the graves of dreams allowed to die

Dec 1 '07 #42