Global Variables : Where are they stored ?

[Flash Gordon]

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

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-Memory_Layout_And_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/2005/02/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.

 

[Podi]

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?

 

[Podi]

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.

 

[Mark McIntyre]

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.

 

[Mark McIntyre]

On Nov 30, 11:45 am, (e-mail address removed) (Richard Harter) wrote:

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.

 

[Flash Gordon]

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

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]

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

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.

 

[James Kuyper]

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

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.

 

[Flash Gordon]

James Kuyper wrote, On 01/12/07 15:16:

That would not be conforming, not even under the more relaxed rules that
apply to freestanding implementations.

Yes, that was my point.

I believe that it is, however, a
common non-conforming mode, in fact often the default mode, for
compilers for embedded systems.

Add the work "some" in to your sentence. I have worked on embedded
systems where it was definitely not true since the processor (and
compiler) did not support anything smaller than a 16 bit integer type. I
did find one non-conformance in the implementation (one I found rather
annoying), but I was able to fix that by changing the application
startup code.

 

[Richard Harter]

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.

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, (e-mail address removed)
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

 

[freepsps77]

Hi,

I just wanted to ask if any of you guys is at MateCube yet... It seems
to be the latest crazy in social networking.

If not, check it out and tell me what you think: http://www.matecube.com

Jak