C Interview Questions

R

Richard Heathfield

(e-mail address removed) said:

"C and C++ Basic Questians" didn't inspire a lot of confidence. Still, let's
see:

1. What is the function of ceil(X) defined in math.h do?

Since ceil is not defined in math.h, this is a tricky one to answer!

2. When do you say that a digraph is acyclic

What has this to do with C?

5. Which of the Following [functions] is not defined in string.h?

All of them, obviously.

6. .Identify the correct argument for the function call fflush() in ANSI C:

None of the candidate answers is uniquely correct. Three are wrong, and
stdout is only /one/ correct argument for fflush.

7. Which of the Following will define a type NODE that is a node in a Linked
list?

None of the candidate answers is correct.

10. Look at the Code: ... What will be the output?

Since the code won't compile, the question is moot.

....and so on and so on. These are really just edited lowlights.

Thanks. I've notified Prentice Hall.
 
A

Adrian

Richard said:
(e-mail address removed) said:

6. .Identify the correct argument for the function call fflush() in ANSI C:

None of the candidate answers is uniquely correct. Three are wrong, and
stdout is only /one/ correct argument for fflush.

Richard, could you tell me why all three are wrong. I thought stdin, stdout,
stderr where all macros to FILE * for the 3 streams. Now the standard does say
for buffered streams, are they not buffered?

Also the standard says you can pass NULL to fflush to flush all open streams.

Thanks

Adrian
 
J

J. J. Farrell

Richard said:
(e-mail address removed) said:


"C and C++ Basic Questians" didn't inspire a lot of confidence. Still, let's
see:

2. When do you say that a digraph is acyclic

What has this to do with C?

C99 has digraphs, and I'd say they're always acyclic.
5. Which of the Following [functions] is not defined in string.h?

All of them, obviously.

Implementation specific, perhaps? Does anything prevent an
implementation defining them in the header if it chooses to?
...
...and so on and so on. These are really just edited lowlights.

Indeed.
 
K

Keith Thompson

J. J. Farrell said:
C99 has digraphs, and I'd say they're always acyclic.

The digraphs are:

<: :> <% %> %: %:%:

Four of them include percent signs which include little circles. So
only said:
5. Which of the Following [functions] is not defined in string.h?

All of them, obviously.

Implementation specific, perhaps? Does anything prevent an
implementation defining them in the header if it chooses to?
[...]

If a header contains a function definition, and that header is
included in two or more translation units in the same program, Bad
Things Could Happen. (I'm too lazy to figure out whether it's
undefined behavior, a constraint violation, or whatever.)

Then again, the predefined functions can also be defined as macros.
 
O

Old Wolf

Keith said:
If a header contains a function definition, and that header is
included in two or more translation units in the same program, Bad
Things Could Happen. (I'm too lazy to figure out whether it's
undefined behavior, a constraint violation, or whatever.)

Bad things don't happen if the function definitions are static,
or if it is C99 and they are inline
 
R

Richard Heathfield

Adrian said:
Richard, could you tell me why all three are wrong.

Um, make that two. :) (And neither of the other two is uniquely correct,
so it's still a big deal from a getting-the-right-answer perspective.)
While there isn't much point in fflushing stderr, it's legal. But fflush is
only well-defined for streams open for update or output, which stdin is
not. So the answer cannot be A, because that would suggest C is wrong,
cannot be B because it's wrong, cannot be C because that would suggest A is
wrong, and cannot be D because B is wrong.
Also the standard says you can pass NULL to fflush to flush all open
streams.

Indeed, which is another reason that there is no such thing as *the* correct
argument to fflush.
 
R

Richard Heathfield

J. J. Farrell said:
C99 has digraphs, and I'd say they're always acyclic.

Bad dog! No biscuit! :)
5. Which of the Following [functions] is not defined in string.h?

All of them, obviously.

Implementation specific, perhaps? Does anything prevent an
implementation defining them in the header if it chooses to?

I can find no licence in the Standard that allows it. The most relevant
paragraph appears to be:

4.1.2 Standard headers

Each library function is declared in a header, /81/ whose contents
are made available by the #include preprocessing directive. The
header declares a set of related functions, plus any necessary types
and additional macros needed to facilitate their use. Each header
declares and defines only those identifiers listed in its associated
section. All external identifiers declared in any of the headers are
reserved, whether or not the associated header is included. All
external identifiers that begin with an underscore are reserved. All
other identifiers that begin with an underscore and either an
upper-case letter or another underscore are reserved. If the program
defines an external identifier with the same name as a reserved
external identifier, even in a semantically equivalent form, the
behavior is undefined./82/

It seems to me that this does not give permission for implementations to
define standard library functions in standard headers, although it does
mandate that they be declared therein.
 
G

Guest

Richard said:
J. J. Farrell said:
Richard said:
5. Which of the Following [functions] is not defined in string.h?

All of them, obviously.

Implementation specific, perhaps? Does anything prevent an
implementation defining them in the header if it chooses to?

I can find no licence in the Standard that allows it.

If there is no way for an otherwise strictly conforming program to tell
the difference, there doesn't have to be any explicit licence that
allows it.
 
R

Richard Heathfield

Harald van D?k said:
Richard said:
J. J. Farrell said:
Richard Heathfield wrote:
5. Which of the Following [functions] is not defined in string.h?

All of them, obviously.

Implementation specific, perhaps? Does anything prevent an
implementation defining them in the header if it chooses to?

I can find no licence in the Standard that allows it.

If there is no way for an otherwise strictly conforming program to tell
the difference, there doesn't have to be any explicit licence that
allows it.

Although I don't claim to have thought it through, I can't help wondering
about standard library functions that use static buffers. There may be a
way for strictly conforming programs to detect that, in two different
modules of the program, different static buffers are being used. (And yes,
okay, perhaps the library could be organised to get around this, by using
buffers with external linkage, but it's getting very messy.)
 
S

Simon Biber

Richard said:
Adrian said:

Indeed, which is another reason that there is no such thing as *the* correct
argument to fflush.

Q: Which is the integer?
A: 23
B: 52.3
C: 22.1
D: -99.1

Obviously 23 is the integer. It's not the only integer in the universe,
but it's the integer in the list following. That's how English works.
 
R

Richard Heathfield

Simon Biber said:
Q: Which is the integer?
A: 23
B: 52.3
C: 22.1
D: -99.1

Obviously 23 is the integer.
It's not the only integer in the universe,
but it's the integer in the list following. That's how English works.

Point taken. Now, which is the correct argument to fflush?

a) stdout
b) stdin
c) stderr
d) All the above
 
W

William Hughes

Richard said:
Harald van D?k said:
Richard said:
J. J. Farrell said:
Richard Heathfield wrote:
5. Which of the Following [functions] is not defined in string.h?

All of them, obviously.

Implementation specific, perhaps? Does anything prevent an
implementation defining them in the header if it chooses to?

I can find no licence in the Standard that allows it.

If there is no way for an otherwise strictly conforming program to tell
the difference, there doesn't have to be any explicit licence that
allows it.

Although I don't claim to have thought it through, I can't help wondering
about standard library functions that use static buffers. There may be a
way for strictly conforming programs to detect that, in two different
modules of the program, different static buffers are being used. (And yes,
okay, perhaps the library could be organised to get around this, by using
buffers with external linkage, but it's getting very messy.)


How about not all functions are defined in the header, in particular
no function that uses a static buffer? I.e. could some functions
be defined static in the header (e.g. to simplify inlining)?. As
different
modules would have different versions of the function, this could be
detected by taking function addresses and comparing. But is there
anything in the standard that prevents this?

(Linker magic may be possible, (e.g. for some library functions (even
when declared
static) first resolve the name by looking in a library, and only if it
is not found
there resolve the name using the object file). Do not report name
conflicts
for these library functions. Yech! But is it possible? )

- William Hughes
 
B

Bart

Simon said:
Q: Which is the integer?
A: 23
B: 52.3
C: 22.1
D: -99.1

Obviously 23 is the integer. It's not the only integer in the universe,
but it's the integer in the list following. That's how English works.

I thought 42 is *the* integer. ;)


Regards,
Bart.
 
J

james of tucson

Richard said:
BTW, I've discovered what TQOLTUAE is.

It's "What is the total value of all balls on a snooker table?"

$2.50 per hour; $1.00 with student ID?
 
A

Adrian

Richard said:
Um, make that two. :) (And neither of the other two is uniquely correct,
so it's still a big deal from a getting-the-right-answer perspective.)
While there isn't much point in fflushing stderr, it's legal. But fflush is
only well-defined for streams open for update or output, which stdin is
not. So the answer cannot be A, because that would suggest C is wrong,
cannot be B because it's wrong, cannot be C because that would suggest A is
wrong, and cannot be D because B is wrong.


Indeed, which is another reason that there is no such thing as *the* correct
argument to fflush.

Thanks, I thought you were saying there was some reason you couldn't pass those
to fflush. Got you now.


Adrian
 
E

Eric Sosman

Richard Heathfield wrote On 10/31/06 07:43,:
Simon Biber said:




Point taken. Now, which is the correct argument to fflush?

a) stdout
b) stdin
c) stderr
d) All the above

#include <stdio.h>
int main(void) {
fputs ("The correct answer is\n", stdout);
fflush (stdout);
if (freopen(NULL, "w", stdin) == NULL) {
fputs ("indeterminate.\n", stderr);
fflush (stderr);
}
else {
fputs ("d: all of the above!\n", stdin);
fflush (stdin); /* 100% legal! */
}
return 0;
}
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
474,431
Messages
2,571,678
Members
48,796
Latest member
Greg L.

Latest Threads

Top