Some Questions Asked in Interview

[Joe Wright]

|> Mabden wrote:

|> >>Q1 . What is the use of pointer to an array?
|> > TO step through the array, or pass it by reference to another
|> > function.

|> You can't step through an array using a pointer to it. If you
|> increment a pointer to an array by 1 you will point one past the end
|> of the object (the array in this case) this is defined, but you
|> cannot dereference this pointer as that leads to undefined
|> behaviour.

|> A pointer to an array is rarely useful, I have never had the need
|> for one.

Nonsense. If a is a two dimensional array, the expression a returns
a pointer to an array.

Nonsense. C does not have multi dimensional arrays. Only arrays of
arrays. The expression of an array yields (not returns) the address
of its first element. It's all about decadence.

int i = 0;

char a[5][10];

This defines (creates) exactly 50 bytes of memory. An array [5] of
array [10] of char.

Expressing a yields 'pointer to array [10] of char'. Expressing a
yields 'pointer to char'. It would be &a to get 'pointer to array
[10] of char'.

 

[Arthur J. O'Dwyer]

(e-mail address removed)-berlin.de writes:
|> > |> A pointer to an array is rarely useful, I have never had the
|> > |> need for one.

|> > Nonsense. If a is a two dimensional array, the expression a
|> > returns a pointer to an array.

|> Well, let's look at that. [The above assertion is wrong.]

I think you'll agree that if a is declared as a 2 diminsional array, the
expression a + i is a pointer to an array.

Yes.

Although my example went a step too far -- I should have said a+i,
rather than a (which is, of course *(a+i)). But the point remains;
you cannot use two dimensional arrays in C without using pointers to
arrays. Even if typically, you don't write them explicitly.

That's just as nonsensical an argument as saying that most C
programs use non-trivial language parsers. You're arguing that
the program "uses" something supplied invisibly by the compiler
(or the language definition). I don't think this is what Thomas
meant.

Another obvious case, of course: what is the type of the parameter of:
int f( int a[5][5] ) ;

Pointer to array[5] of 'int', of course. But I have never written
a program that needed to know or use the type of the parameter in
such a function; normally, I use 'a' as if it were an array of arrays
of 'int'. Which the language syntax encourages me to do, of course.
I, like Thomas, have never to my knowledge used a declaration of the
form

foo (*bar)[baz];

in anything other than joke code. As he says, pointers to arrays
are hardly ever useful.

-Arthur

 

[Old Wolf]

It seems to be a common misconception that with

int b[ 20 ];

'b' would be of type "pointer to array". But 'b' is of type "pointer to
int", pointing to the first element of the array

If that were true, then sizeof(b) would equal sizeof(int *),
and it would be legal to write: int *const *p = &b; p[0][0] = 1; etc.

 

[CBFalconer]

.... snip ...

In my experience, such "quizzes" are most useful if given orally
and interactively by someone familiar with the topic. Less
formally, I suspect that most people called on to vet a number of
so-called specialists will make up a list of questions to start
with. After the first few, of course, you play it by ear,
adjusting to the apparent competence of the person being
interviewed.

Or the inverse, with the interviewee adjusting to the apparent
competence of the interviewer. But beware 'apparent', s/he may be
setting traps.

 

[Thomas stegen]

You are assuming I am incompetent.

Your assumption about my assumption is wrong. I am now assuming
that you are ignorant about the difference between a pointer to
an array and a pointer to the first element in the array.

I would either keep a count on members or
add a terminating value to the array. Running off the end, or "off by one"
is a common error that one must plan to handle. Please don't tell me I can't
do something because you see a trivial restriction.

Don't attribute to stupidity or ignorance what can be attributed to
competence.

Or something

It so happens I do know what I am talking about.

If I have for example,

int a[5];

An array. If I want a pointer to that array I need to do something
along the lines of

int (*p)[5];

Now I can do,

p = &a;

I cannot do,

p = a;

Since that is not allowed.

Now doing p + 1 will not allow me to access the second element in
the array designated by a.

When you say "you can't"
I think of going to the moon. You would have said the same thing back then,
"you can't"

I can.

Oh, so I am a stubborn conservative? I am against progress? I
find this quite offensive. Back then I would have said "yes we can"
by the way. At least I think I would have, based on the evidence I can
glean from my attitudes to other similar things today.

 

[James Kanze]

|> James Kanze wrote:

|> > |> Mabden wrote:
|> > |> >>Q1 . What is the use of pointer to an array?
|> > |> > TO step through the array, or pass it by reference to another
|> > |> > function.

|> > |> You can't step through an array using a pointer to it. If you
|> > |> increment a pointer to an array by 1 you will point one past
|> > |> the end of the object (the array in this case) this is
|> > |> defined, but you cannot dereference this pointer as that leads
|> > |> to undefined behaviour. A pointer to an array is rarely
|> > |> useful, I have never had the need for one.

|> > Nonsense. If a is a two dimensional array, the expression a
|> > returns a pointer to an array.

|> Nonsense. C does not have multi dimensional arrays. Only arrays of
|> arrays.

OK. Formally, what C uses for multi dimensional arrays is in fact
arrays of arrays. Formally, what C uses for indexing is pointer
arithmetic.

|> The expression of an array yields (not returns) the address of its
|> first element.

No. An expression of array type yields an array. Which will convert
implicitly to a pointer in certain contexts only. And the conversion
obviously doesn't continue, because what you get after the decay is a
pointer, not an array.

And of course, if what you have is an array of arrays, what the decay
gives you is a pointer to an array.

|> It's all about decadence.

|> int i = 0;

|> char a[5][10];

|> This defines (creates) exactly 50 bytes of memory. An array [5] of
|> array [10] of char.

|> Expressing a yields 'pointer to array [10] of char'.

You mean, like in &a, or sizeof( a )?

Of course, in contexts where the decay occurs... Well, that's exactly my
point. You have a pointer to an array.

|> Expressing a yields 'pointer to char'.

No, it yields an array [10] of char, which isn't the same thing.

Try sizeof( a ), for example.

|> It would be &a to get 'pointer to array [10] of char'.

How about a + i?

 

[James Kanze]

[...]
|> As he says, pointers to arrays are hardly ever useful.

And you missed my point. Explicit pointers to arrays are hardly ever
useful; like you, I find the declaration syntax complex enough to render
code using them pretty unreadable to many people. But that wasn't what
he said. Implicit pointers to arrays occur in just about any program
which uses "multi-dimensional arrays".

 

[James Kanze]

|> James Kanze wrote:

|> ... snip ...

|> > In my experience, such "quizzes" are most useful if given orally
|> > and interactively by someone familiar with the topic. Less
|> > formally, I suspect that most people called on to vet a number of
|> > so-called specialists will make up a list of questions to start
|> > with. After the first few, of course, you play it by ear,
|> > adjusting to the apparent competence of the person being
|> > interviewed.

|> Or the inverse, with the interviewee adjusting to the apparent
|> competence of the interviewer. But beware 'apparent', s/he may be
|> setting traps.

The role of an interview is both parties to learn more about the other.
Setting traps isn't normally an effective way to learn much; if you
can't establish some sort of open dialog during the interview, it is
probable that you won't be able to establish much of one afterwards
either. In which case, you're better off not taking the job (providing
the market and your finances give you a choice).

 

[Dan Pop]

|> Mabden wrote:

|> >>Q1 . What is the use of pointer to an array?
|> > TO step through the array, or pass it by reference to another
|> > function.

|> You can't step through an array using a pointer to it. If you
|> increment a pointer to an array by 1 you will point one past the end
|> of the object (the array in this case) this is defined, but you
|> cannot dereference this pointer as that leads to undefined
|> behaviour.

|> A pointer to an array is rarely useful, I have never had the need
|> for one.

Nonsense. If a is a two dimensional array, the expression a returns
a pointer to an array.

That immediately decays into a pointer to its first element, with the
known exceptions.

Dan

 

[Dan Pop]

Here are some questions on C/C++, OS internals?

You should have posted *only* those related to C here.

Q1 . What is the use of pointer to an array?

In the rare cases when the size of the array is known at compile time, it
simplifies the dynamic allocation of bidimensional arrays. Extend to
multidimensional arrays where only the first dimension can be variable.

Q2 . What is the use of array of pointers?

Far too many to be worth enumerating. argv is a typical example.

Q3 . What is the use of pointer to function ?

Callbacks and encapsulation, among many others.

Q4 . How to print through serial port? What is Flow Control(Xon,Xoff)
?
Q5 . What is IOCTL Explain .
Q6 . How to create an interrupt service routine in C?
Q7 . What are the internals of a schedular ?

These are not C questions. C provides no support for interrupt handlers.

Q8 . The static variables are declared in heap or stack ?

Is this an ad litteram rendition of the original interview question?

Static variables are declared in neither heap nor stack, they are declared
in C source code files. And they are *allocated* whereever the
implementor chooses to, typically neither in heap (the malloc and friends
arena) nor in stack (automatic allocation arena and function call related
data).

Dan

 

[glen herrmannsfeldt]

(e-mail address removed)-berlin.de wrote:

(snip)

Well, lets look at that. As you probably know very well there aren't
any true multidimensional arrays in C, they are basically syntactic
sugar, made up from flat, one-dimensional arrays. And the rules for
such arrays, like for example

Well, at least C has the memory layout of a multidimensional
array. Java doesn't even have that. Java will allocate an
array of pointers, (called object reference variables, to
pretend that it doesn't have pointers), each pointing to an array.

What do they have to be to be true?

(snip)

-- glen

 

[Mark McIntyre]

It seems to be a common misconception that with

int b[ 20 ];

'b' would be of type "pointer to array". But 'b' is of type "pointer to
int", pointing to the first element of the array

If that were true, then sizeof(b) would equal sizeof(int *),

Indeed. As far as I remember,, b is of type "array[20] of int".

and it would be legal to write: int *const *p = &b; p[0][0] = 1; etc.

But it is, provided you first pass b to a function...

 

[RoSsIaCrIiLoIA]

"We put [the best] Assembler programmers in a little glass case in the hallway
near the Exit sign. The sign on the case says, `In case of optimization
problem, break glass.' Meanwhile, the problem solvers are busy doing their
work in languages most appropriate to the job at hand." --Richard Riehle

Every computer were in the net
every programmes were happy with they not-low language
but
there was a multi-platform virus it was able to enter in any OS and
at date xx.xx.xxxx it checked if it was in every computer in the net
and the answer was *yes*: so started his job: destroy every executable
and source file wrote before 1990.

There was a disaster!
Assembler programmers were in a little glass case in the hallway
near the Exit sign. The sign on the case says, `In case of
optimization problem, break glass.'

Programmers broken the glas and ask to rewrite all the lost software
because their Pc were OFF
The answer was: "we doing optimization only, and doesn't know were to
start for rewriting them". It was the end of the story.

 

[Mabden]

"We put [the best] Assembler programmers in a little glass case in the hallway
near the Exit sign. The sign on the case says, `In case of optimization
problem, break glass.' Meanwhile, the problem solvers are busy doing their
work in languages most appropriate to the job at hand." --Richard Riehle

Every computer were in the net
every programmes were happy with they not-low language
but
there was a multi-platform virus it was able to enter in any OS and
at date xx.xx.xxxx it checked if it was in every computer in the net
and the answer was *yes*: so started his job: destroy every executable
and source file wrote before 1990.

There was a disaster!
Assembler programmers were in a little glass case in the hallway
near the Exit sign. The sign on the case says, `In case of
optimization problem, break glass.'

Programmers broken the glas and ask to rewrite all the lost software
because their Pc were OFF
The answer was: "we doing optimization only, and doesn't know were to
start for rewriting them". It was the end of the story.

Or in English:

I remember the day when every computer in the world was connected to the
Internet. All the Operating Systems and the programs they ran were
high-level object-oriented masterpieces. All the programmers were high-level
object-oriented programmers. But, there was a multi-platform virus that no
one knew about. It was able to enter any OS on any platform.

And on date xx.xx.xxxx the virus checked, as it had been doing every day, to
see if every computer on the Internet was infected. The answer was, "Yes!"
So the virus began its task; Destroy every executable program and source
file that were written before the year 1990!

There was world wide disaster and panic! But not to worry - there was still
the little glass case at the end of the hall, by the fire escape, in the
basement. In it were the last of the Assembler Programmers. A little sign on
the glass read, "Break glass in case of optimization problem." And there was
a tiny steel hammer hanging next to the box, on a chain.

The modern high-level object-oriented programmers breathed a sigh of relief
as they wiped the dust from the hammer and broke the glass. They begged the
Assembler Programmers to rewrite all the lost software, because the Internet
was all but destroyed and their computers not longer worked.

The Assembler Programmers shuffled their feet, glanced at each other, and
replied, "Uh, we only do optimizations..."

 

[Peter B. Steiger]

I find it alarming that this trend of giving ridiculous quizzes and tests
to interviewee is increasing. When I was young and looking for a job,
companies that did this were few. I immediately walked out of any
interview were I was asked to take such a test. Regurgitation of facts
does not prove knowledge or wisdom, and is certainly no indication of
skill. For someone with an encyclopedic memory of the C or C++ standards,
I would hire for a one-time fee of $18--the amount I would need to just
purchase a copy of the standard (or whatever it currently costs).

My first "real" programming job followed an interview that had little to
do with computers. Once the interviewer found out I shared his love for
the movie "Airplane!", we spent most of the time exchanging favorite
quotes from that movie. Somewhere in there he shoved a printout of some
Clipper code (the language I knew and he needed at the time) across the
desk and asked me to translate a few lines to English, which I did, but to
this day I'm convinced that I got the job because I knew the proper
response to "Surely you can't be serious!"

 

[Joe Wright]

|> James Kanze wrote:

|> > |> Mabden wrote:
|> > |> >>Q1 . What is the use of pointer to an array?
|> > |> > TO step through the array, or pass it by reference to another
|> > |> > function.

|> > |> You can't step through an array using a pointer to it. If you
|> > |> increment a pointer to an array by 1 you will point one past
|> > |> the end of the object (the array in this case) this is
|> > |> defined, but you cannot dereference this pointer as that leads
|> > |> to undefined behaviour. A pointer to an array is rarely
|> > |> useful, I have never had the need for one.

|> > Nonsense. If a is a two dimensional array, the expression a
|> > returns a pointer to an array.

|> Nonsense. C does not have multi dimensional arrays. Only arrays of
|> arrays.

OK. Formally, what C uses for multi dimensional arrays is in fact
arrays of arrays. Formally, what C uses for indexing is pointer
arithmetic.

|> The expression of an array yields (not returns) the address of its
|> first element.

No. An expression of array type yields an array. Which will convert
implicitly to a pointer in certain contexts only. And the conversion
obviously doesn't continue, because what you get after the decay is a
pointer, not an array.

This seems argumentive but, the argument to sizeof is either an
object or a type. The compiler yields the size of it in bytes. The
argument to sizeof is never evaluated and is not an expression.

And of course, if what you have is an array of arrays, what the decay
gives you is a pointer to an array.

|> It's all about decadence.

|> int i = 0;

|> char a[5][10];

|> This defines (creates) exactly 50 bytes of memory. An array [5] of
|> array [10] of char.

|> Expressing a yields 'pointer to array [10] of char'.

You mean, like in &a, or sizeof( a )?

You're missing something. &a is an address by definition. sizeof &a
is 4 at my house. sizeof a yields 50.

Of course, in contexts where the decay occurs... Well, that's exactly my
point. You have a pointer to an array.

|> Expressing a yields 'pointer to char'.

No, it yields an array [10] of char, which isn't the same thing.

Try sizeof( a ), for example.

You're much too hung up on sizeof. Arguments to sizeof are not
expressions. sizeof a is 10. Interesting but unimportant.

char *cp = a;

is correct.

char (*ap)[10] = &a;

is also correct.

|> It would be &a to get 'pointer to array [10] of char'.

How about a + i?

Looks like &a to me. What do you think?

 

[pete]

This seems argumentive but, the argument to sizeof is either an
object or a type. The compiler yields the size of it in bytes. The
argument to sizeof is never evaluated and is not an expression.

The argument to sizeof is never evaluated
but it can be an expression.
An object identifier, is an expression.

 

[Richard Bos]

The argument to sizeof is never evaluated

This is true in C89. In C99, it may be necessary to evaluate a sizeof
argument - this is done if and only if it is a variable-length array.

but it can be an expression.

This is true. To be precise, it's a unary-expression.

Richard

 

[Irrwahn Grausewitz]

[...] the argument to sizeof is either an
object or a type. The compiler yields the size of it in bytes. The
argument to sizeof is never evaluated and is not an expression.

Arguments to sizeof are not
expressions. sizeof a is 10. Interesting but unimportant.

Nitpick:

Since sizeof is not a function, there are no such beasts like
"arguments to sizeof"; sizeof is an unary operator and therefore
has exactly one operand, which has to be either an expression (sic!)
or the parenthesized name of a type.

You're of course right in stating that expressions used as operands
of sizeof are not examined for their value ("evaluated"), but their
type - this therefore one of the notable exceptions to Chris Torek's
"The Rule" [1] (when being operand of the address operator is the
other exception).

This concept makes it BTW possible to evaluate the sizeof operator
at compile-time rather than run-time (again with one notable
exception: C99 variable-length arrays, for obvious reasons).


[1] "In any value context, an object of type 'array of T' is
converted to a value of type 'pointer to T', pointing to
the first element of that array."

Regards

 

[Dan Pop]

This seems argumentive but, the argument to sizeof is either an
object or a type. The compiler yields the size of it in bytes. The
argument to sizeof is never evaluated and is not an expression.

^^^^^^^^^^^^^^^^^^^^^^^^
What's wrong with sizeof(1 + 1)?

Even worse, in C99 evaluation may be needed, when the argument is a VLA:

extern int n, m;
sizeof(int [n + m]);

Dan