i need some C/C++ test intervie questions - Page 3

"Kevin D. Quitt" wrote:

.... snip ...
I doubt I'd be interviewing any of you, and if I were, it wouldn't
include the test. More along the lines of "You can't do any
better than here?".

You mean you are hiring? I can be bought. :-)

--
Replies should be to the newsgroup
Chuck Falconer, on vacation.

Nov 13 '05 #102

Ben Pfaff wrote:

Martin Dickopp <ex*************@zero-based.org> writes:
Out of curiosity, would you allow the applicant to look into
the C standard? After all, I can also consult the standard
while actually programming.

Out of curiosity, how many people actually do this? I know that
I fairly often refer to it myself while programming and have even
cited bits of it in debates at the office (VMware at the moment,
Stanford later this month).

I do, routinely. I have an alias setup to access (more or less)
the relevant portions, which is why I want a text version of the
standard. N869 comes to mind. The machinery seems to have a
better memory than mine.

--
Replies should be to the newsgroup
Chuck Falconer, on vacation.

Nov 13 '05 #103

Richard Heathfield wrote:

.... snip ...
Okay, I'm listening. Here's the question: is the behaviour of
this program well-defined?

#include <stdio.h>
#include <ctype.h>

int main(void)
{
char buf[] = "hello world";
char *p = buf;
p[-1] = (toupper)(*p++); /* This is the trouble spot. */
printf("%s\n", buf);
return 0;
}

When I first saw this, I thought "no way". Then, after discussions
with a clc regular and much thumbing of the Standard, I began to
come to the conclusion that it might be okay (for suitably
pedantic values of "okay", obviously -- the code sucks, after all).

But I'm no longer certain, because... well, never mind! Is it
well-defined? If so, why? If not, why not?

No way. The destination p[-1] *may* be calculated on the
statement entry value of p, which will create an illegal pointer
before the actual storage.

--
Replies should be to the newsgroup
Chuck Falconer, on vacation.

Nov 13 '05 #104

Kevin Easton wrote:

Richard Heathfield <do******@address.co.uk.invalid> wrote:
Martin Dickopp wrote:
Richard Heathfield <do******@address.co.uk.invalid> writes:

Consult the standard during office debates? Well, it's rare. The usual
reaction to "let me just show you the bit..." is "Rich! Rich! We
***believe*** you, okay?!?!?!?!?!"

I just /hate/ it when people believe me. I don't want them to believe
me, I want them to believe the facts, even if I have stated the facts
correctly.
Yes, the difficulty is when you give a confident answer, they go off
happily, and then later you realise that perhaps it wasn't as clear-cut
as you thought.
Therefore, when somebody asks me a question, I usually insist that he
listens to the complete answer, which often involves quoting from the
standard. ;)

Okay, I'm listening. Here's the question: is the behaviour of this
program well-defined?

#include <stdio.h>
#include <ctype.h>

int main(void)
{
char buf[] = "hello world";
char *p = buf;
p[-1] = (toupper)(*p++); /* This is the trouble spot. */
printf("%s\n", buf);
return 0;
}

When I first saw this, I thought "no way". Then, after discussions with a
clc regular and much thumbing of the Standard, I began to come to the
conclusion that it might be okay (for suitably pedantic values of "okay",
obviously -- the code sucks, after all).

But I'm no longer certain, because... well, never mind! Is it
well-defined? If so, why? If not, why not?

Surely not, because the indicated line both modifies p and uses its
value for a purpose other than calculating its new value without an
intervening sequence point (the sequence point before the function call
is not necessarily intervening, because there isn't a total ordering
between the modification and use of p).

That was quick. You're right in that the "timing" of the sequence point is
vital to the answer.
If that doesn't convince you,
This is the trouble. I was convinced twice already, in opposite directions.
:-)
the above is equivalent to (by the
definition of the [] operator):

*(p - 1) = (toupper)(*p++);

...and there is nothing to prevent this ordering:

Calculate p - 1 => temp 1
Calculate p + 1 => temp 2
Fetch value pointed to by temp 2 => temp 3
Store temp 2 into p
Call toupper function with temp 3 as argument
Store result into object pointed to by temp 1

(The order of evaluation of the subexpressions making up the operands to
the = operator isn't defined).

That's basically the only way to break it, I think. I'll have another plough
through C99 next time I get a chance.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

Nov 13 '05 #105

Richard Heathfield <do******@address.co.uk.invalid> writes:

Okay, I'm listening. Here's the question: is the behaviour of this program
well-defined?

#include <stdio.h>
#include <ctype.h>

int main(void)
{
char buf[] = "hello world";
char *p = buf;
p[-1] = (toupper)(*p++); /* This is the trouble spot. */
printf("%s\n", buf);
return 0;
}

This is certainly an example where I would have quoted the standard if I'd
been the first to answer. :)

First of all, `p' is obviously modified and used to determine the
/location/ to be stored to (as opposed to the value to store), so the
behavior is undefined according to 6.5#2 /unless/ there's an intervening
sequence point. It remains to be shown that the sequence point before the
`toupper' call is not guaranteed to happen between these two operations.
According to 6.5#3, "the order of evaluation of subexpressions and the
order in which side effects take place are both unspecified."

Martin

Nov 13 '05 #106

Bill Reed wrote:

On Wed, 3 Sep 2003 10:32:51 -0500, Randy Howard
jd********@ntlworld-not.com says...
Kevin D. Quitt wrote:

> As an occasional interviewer, I find I have to give a test.
> The first question asks the applicant to rate their knowledge
> of C from 1 to 10, where 1 is "What's C?" and 10 is "I'm
> Dennis Ritchie". I use this to set my expectation of the
> results from the rest of the test.

What if the reply is "Who?" ?

*gasp*

You're right. "Who is Dennis Ritchie?"

Didn't he have something to do with the Commodores?

Illustrating the foolishness of such a question. It has nothing
to do with the programmers abilities, but much to do with his
historical knowledge, curiosity, and exposure. In this country
(USA) at least, asking the man/woman in the street simple
historical questions, or even geographical questions, can produce
the most amazing gaffes. Leno takes advantage of this to
generate humor on his program.

I cannot remember the name offhand (I will refer to him as R),
but there was an Indian mathematician, totally untutored, who
wrote GH Hardy with some observations, and was thus discovered as
a major mathematical force. Hardy brought R to Cambridge (or
Oxford??) and R made major contributions to the mathematical
world. However R initially knew absolutely nothing about the
historical development and contributors to mathematics, such as
Newton, Gauss, Dedekind, and many others.

--
Replies should be to the newsgroup
Chuck Falconer, on vacation.

Nov 13 '05 #107

Tom Zych

Richard Heathfield wrote:

...is the behaviour of this program well-defined?

#include <stdio.h>
#include <ctype.h>

int main(void)
{
char buf[] = "hello world";
char *p = buf;
p[-1] = (toupper)(*p++); /* This is the trouble spot. */
printf("%s\n", buf);
return 0;
}

I'm not a standard C guru (yet). My answer is, it doesn't matter,
because even if one can dig into the standard and show that this
works reliably, it's bad code. You can't tell if it works without
being a language lawyer, and it offers no advantage over clear and
reliable code. It should be rewritten and the original coder
should be shot[1].

[1] If it had been in actual production code instead of a puzzle,
that is.

--
Tom Zych
This email address will expire at some point to thwart spammers.
Permanent address: echo 'g******@cbobk.pbz' | rot13

Nov 13 '05 #108

Paul Hsieh

oz****@spamenot.bigpond.com (ozbear) wrote:

On Tue, 02 Sep 2003 22:41:56 GMT, qe*@pobox.com (Paul Hsieh) wrote:
do**********@spamhate.com says...
Personally, in my job hunting days, I walked out on an interviewer that
presumed to give me a test. I find the practice insulting.
I only wish all candidates who objected to being tested would do this -- I
hate wasting my time with the likes of people like you.

Ditto.

If any sort of "exam" is to be part of an interview, it should be
stated beforehand.

I would expect an "exam" from any interview. When *I* am interviewed,
I generally think twice before accepting a position where I have not
been tested (because it means my coworkers were not tested, and
therefore may be of questionable skill ...)
Those of us who have been in the game for decades find this sort of
practice demeaning,
For me, its completely the opposite. In the time it takes to
interview *I* can only get a fair assessment from an interviewer if I
have been given the opportunity to demonstrate exactly where my skill
level is. If they don't test me, then they are treating me like a
checkbox. I've worked at companies that have taken both points of
view and found that my compensation was usually higher at the places
where I was more seriously scrutinized during the interview.

At two of the companies I've worked for I was *used* as an "acid test"
kind of interviewer, because I had built up a number of standard
questions so that my boss could understand my assessment.
[...] and a good indication that it is a job we don't
want anyway.
I don't know who this "we" is. I find that the length of a person's
career is not any kind of indicator of the skill level of the person I
am interviewing. Often such people have lost touch with leading edge
development ideas.
[...] Therefore, it saves time on both persons' parts.

Agreed.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

Nov 13 '05 #109

Tom Zych

LibraryUser wrote:

You're right. "Who is Dennis Ritchie?" Didn't he have something to do with the Commodores?

Illustrating the foolishness of such a question. It has nothing
to do with the programmers abilities, but much to do with his
historical knowledge, curiosity, and exposure. <snip>
I cannot remember the name offhand (I will refer to him as R),
Ramanujan.
but there was an Indian mathematician, totally untutored, who
wrote GH Hardy with some observations, and was thus discovered as
a major mathematical force. Hardy brought R to Cambridge (or
Oxford??) and R made major contributions to the mathematical
world. However R initially knew absolutely nothing about the
historical development and contributors to mathematics, such as
Newton, Gauss, Dedekind, and many others.

An interesting parallel. IIRC, Ramanujan learned from one book and
figured out the rest on his own. You can do that with math[1],
because math is self-contained and deductive. Theoretically, I
suppose one could read one C book (which didn't mention Ritchie or
other C luminaries), then use a compiler and man pages to become
expert.

OTOH, I think curiosity counts for a lot in programming. And
experience is hard to obtain without exposure to a wider body of
literature.

[1] Well, if you're Ramanujan, you can :)

--
Tom Zych
This email address will expire at some point to thwart spammers.
Permanent address: echo 'g******@cbobk.pbz' | rot13

Nov 13 '05 #110

Irrwahn Grausewitz

LibraryUser <de**********@made.invalid> wrote:
<SNIP>

I cannot remember the name offhand (I will refer to him as R),
but there was an Indian mathematician, totally untutored, who
wrote GH Hardy with some observations, and was thus discovered as
a major mathematical force. Hardy brought R to Cambridge (or
Oxford??) and R made major contributions to the mathematical
world. However R initially knew absolutely nothing about the
historical development and contributors to mathematics, such as
Newton, Gauss, Dedekind, and many others.

His name actually was Srinivasa Ramanujan (1887-1920), if someone
wants to search for a biography. He moved to England in 1913, and,
unluckily, died young (as you can see from the dates above),
suffering from tubercolosis.

--
6 * 9 = 42 (base 13)

Nov 13 '05 #111

"Kevin D. Quitt" wrote:

.... snip ...
I doubt I'd be interviewing any of you, and if I were, it wouldn't
include the test. More along the lines of "You can't do any
better than here?".

You mean you are hiring? I can be bought. :-)

--
Replies should be to the newsgroup
Chuck Falconer, on vacation.

Nov 13 '05 #112

Ben Pfaff wrote:

Martin Dickopp <ex*************@zero-based.org> writes:
Out of curiosity, would you allow the applicant to look into
the C standard? After all, I can also consult the standard
while actually programming.

Out of curiosity, how many people actually do this? I know that
I fairly often refer to it myself while programming and have even
cited bits of it in debates at the office (VMware at the moment,
Stanford later this month).

Nov 13 '05 #113

Richard Heathfield wrote:

.... snip ...
Okay, I'm listening. Here's the question: is the behaviour of
this program well-defined?

#include <stdio.h>
#include <ctype.h>

int main(void)
{
char buf[] = "hello world";
char *p = buf;
p[-1] = (toupper)(*p++); /* This is the trouble spot. */
printf("%s\n", buf);
return 0;
}

When I first saw this, I thought "no way". Then, after discussions
with a clc regular and much thumbing of the Standard, I began to
come to the conclusion that it might be okay (for suitably
pedantic values of "okay", obviously -- the code sucks, after all).

But I'm no longer certain, because... well, never mind! Is it
well-defined? If so, why? If not, why not?

Nov 13 '05 #114

Tom Zych <tz******@pobox.com> writes:

IIRC, Ramanujan learned from one book and figured out the rest on his
own. You can do that with math[1], because math is self-contained and
deductive.

Actually, Kurt Gödel proved that no complete axiomatic system can be free
of undecidable theorems. So not only is mathematics not self-contained and
deductive, but it couldn't even be replaced by an alternative complete
axiomatic system which is. :)

Martin

Nov 13 '05 #115

Richard Heathfield <do******@address.co.uk.invalid> writes:

Okay, I'm listening. Here's the question: is the behaviour of this program
well-defined?

#include <stdio.h>
#include <ctype.h>

int main(void)
{
char buf[] = "hello world";
char *p = buf;
p[-1] = (toupper)(*p++); /* This is the trouble spot. */
printf("%s\n", buf);
return 0;
}

Nov 13 '05 #116

goose

Kevin D. Quitt <KQ****@IEEInc.com> wrote in message news:<5c********************************@4ax.com>. ..

On 4 Sep 2003 13:08:38 -0700, ru**@webmail.co.za (goose) wrote:
The problem i've had is that /any/ company that says "here, write this
test" has the test set by their best in-house programmers. of course,
That would be me. 8o)

that in itself is not a problem, the problem arises when these "best"
programmers aren't.

Well, I am - but I'm not perfect.

glad you realise it :-) no one is. but ttry telling a prima donna
that they write faulty code.

I did, of course, not even consider hearing an offer from the company,
especially when I pointed out the errors in every single question
Anybody who correctly points out an error (other than a deliberate one)
wins.

<sigh> not really. you get labelled as a "lone programmer" (as opposed
to a "team player") if you hurt the prima donnas feelings.

I'd rather not work under anyone with /that/ attitude.
Nor would I. Nor have I.

unfortunately, i /have/ and i might again in the future ... through
no choice of my own (seems to be a downturn at the moment).

and very few want to look at the code I bring in.
I'm generally not interested in seeing an applicant's code unless there's
some special reason for it.

<grin> not even my partially complete rtos written mostly in std C
(with all the platform-specific stuff in seperate files) ???
but i'm *proud* (or rather, was) of it...
All that's going to show me is their
programming idiom, and that can usually be changed if it's egregious. I'd
rather spend the time talking about their programming philosophy and
attitude, and trying to determine if they're going to be a good fit with
the existing crew.

or you can ask them to name the ergs on clc ;-)

goose,

Nov 13 '05 #117

goose

Kevin D. Quitt <KQ****@IEEInc.com> wrote in message news:<08********************************@4ax.com>. ..

On Thu, 4 Sep 2003 01:44:54 +0000 (UTC), Richard Heathfield
<do******@address.co.uk.invalid> wrote:
So I suppose the right answer is that the question is broken, or at least
provides insufficient information to give a meaningful answer. In this
case, however, the right answer is unlikely to get you hired unless the
interviewer is very clueful.
I repeat: this is not a pass/fail exam, and not meant to be scientific.
It is meant mostly as a bullshit detector for people who claim skills they
don't have. When I'm hiring a C programmer, I know about what level of
expertise I'm looking for, and my test includes questions about other than
just C programming.

ah ... see .. any test that tests me on anything /other/ than
C (or any programming language I may claim to know), i'd do badly
on. my experience is a rather limited problem domain.

go on. ask me about emv :-)

<snipped>

While I do not want to make the test public, I will send a copy to anybody
who asks.
ok! my address above is valid.
The answer sheet will cost you, though. 8o)

i'll make my own :-) just dont do a "sco" on me and sue me for stealing
your code :-)

goose,

Nov 13 '05 #118

Bill Reed wrote:

On Wed, 3 Sep 2003 10:32:51 -0500, Randy Howard
jd********@ntlworld-not.com says...
Kevin D. Quitt wrote:

> As an occasional interviewer, I find I have to give a test.
> The first question asks the applicant to rate their knowledge
> of C from 1 to 10, where 1 is "What's C?" and 10 is "I'm
> Dennis Ritchie". I use this to set my expectation of the
> results from the rest of the test.

What if the reply is "Who?" ?

*gasp*

You're right. "Who is Dennis Ritchie?"

Didn't he have something to do with the Commodores?

Nov 13 '05 #119

Tom Zych

Richard Heathfield wrote:

...is the behaviour of this program well-defined?

#include <stdio.h>
#include <ctype.h>

int main(void)
{
char buf[] = "hello world";
char *p = buf;
p[-1] = (toupper)(*p++); /* This is the trouble spot. */
printf("%s\n", buf);
return 0;
}

Nov 13 '05 #120

Tom Zych

LibraryUser wrote:

You're right. "Who is Dennis Ritchie?" Didn't he have something to do with the Commodores?

Illustrating the foolishness of such a question. It has nothing
to do with the programmers abilities, but much to do with his
historical knowledge, curiosity, and exposure. <snip>
I cannot remember the name offhand (I will refer to him as R),
Ramanujan.
but there was an Indian mathematician, totally untutored, who
wrote GH Hardy with some observations, and was thus discovered as
a major mathematical force. Hardy brought R to Cambridge (or
Oxford??) and R made major contributions to the mathematical
world. However R initially knew absolutely nothing about the
historical development and contributors to mathematics, such as
Newton, Gauss, Dedekind, and many others.

Nov 13 '05 #121

Irrwahn Grausewitz

LibraryUser <de**********@made.invalid> wrote:
<SNIP>

I cannot remember the name offhand (I will refer to him as R),
but there was an Indian mathematician, totally untutored, who
wrote GH Hardy with some observations, and was thus discovered as
a major mathematical force. Hardy brought R to Cambridge (or
Oxford??) and R made major contributions to the mathematical
world. However R initially knew absolutely nothing about the
historical development and contributors to mathematics, such as
Newton, Gauss, Dedekind, and many others.

Nov 13 '05 #122

Ben Pfaff

ru**@webmail.co.za (goose) writes:

ah ... see .. any test that tests me on anything /other/ than
C (or any programming language I may claim to know), i'd do badly
on. my experience is a rather limited problem domain.

go on. ask me about emv :-)

What's emv?
--
"Some people *are* arrogant, and others read the FAQ."
--Chris Dollin

Nov 13 '05 #123

Tom Zych <tz******@pobox.com> writes:

IIRC, Ramanujan learned from one book and figured out the rest on his
own. You can do that with math[1], because math is self-contained and
deductive.

Nov 13 '05 #124

goose

Kevin D. Quitt <KQ****@IEEInc.com> wrote in message news:<5c********************************@4ax.com>. ..

On 4 Sep 2003 13:08:38 -0700, ru**@webmail.co.za (goose) wrote:
The problem i've had is that /any/ company that says "here, write this
test" has the test set by their best in-house programmers. of course,
That would be me. 8o)

that in itself is not a problem, the problem arises when these "best"
programmers aren't.

Well, I am - but I'm not perfect.

glad you realise it :-) no one is. but ttry telling a prima donna
that they write faulty code.

I did, of course, not even consider hearing an offer from the company,
especially when I pointed out the errors in every single question
Anybody who correctly points out an error (other than a deliberate one)
wins.

<sigh> not really. you get labelled as a "lone programmer" (as opposed
to a "team player") if you hurt the prima donnas feelings.

I'd rather not work under anyone with /that/ attitude.
Nor would I. Nor have I.

unfortunately, i /have/ and i might again in the future ... through
no choice of my own (seems to be a downturn at the moment).

and very few want to look at the code I bring in.
I'm generally not interested in seeing an applicant's code unless there's
some special reason for it.

<grin> not even my partially complete rtos written mostly in std C
(with all the platform-specific stuff in seperate files) ???
but i'm *proud* (or rather, was) of it...
All that's going to show me is their
programming idiom, and that can usually be changed if it's egregious. I'd
rather spend the time talking about their programming philosophy and
attitude, and trying to determine if they're going to be a good fit with
the existing crew.

or you can ask them to name the ergs on clc ;-)

goose,

Nov 13 '05 #125

goose

Kevin D. Quitt <KQ****@IEEInc.com> wrote in message news:<08********************************@4ax.com>. ..

On Thu, 4 Sep 2003 01:44:54 +0000 (UTC), Richard Heathfield
<do******@address.co.uk.invalid> wrote:
So I suppose the right answer is that the question is broken, or at least
provides insufficient information to give a meaningful answer. In this
case, however, the right answer is unlikely to get you hired unless the
interviewer is very clueful.
I repeat: this is not a pass/fail exam, and not meant to be scientific.
It is meant mostly as a bullshit detector for people who claim skills they
don't have. When I'm hiring a C programmer, I know about what level of
expertise I'm looking for, and my test includes questions about other than
just C programming.

ah ... see .. any test that tests me on anything /other/ than
C (or any programming language I may claim to know), i'd do badly
on. my experience is a rather limited problem domain.

go on. ask me about emv :-)

<snipped>

While I do not want to make the test public, I will send a copy to anybody
who asks.
ok! my address above is valid.
The answer sheet will cost you, though. 8o)

i'll make my own :-) just dont do a "sco" on me and sue me for stealing
your code :-)

goose,

Nov 13 '05 #126

Tom Zych

Martin Dickopp wrote:

Tom Zych <tz******@pobox.com> writes:
IIRC, Ramanujan learned from one book and figured out the rest on his
own. You can do that with math[1], because math is self-contained and
deductive.

Actually, Kurt Gödel proved that no complete axiomatic system can be free
of undecidable theorems. So not only is mathematics not self-contained and
deductive, but it couldn't even be replaced by an alternative complete
axiomatic system which is. :)

Hmm. I don't really see how Gödel's theorem contradicts what I
said. IIRC, he proved that in any sufficiently complex formal
system, there are true statements that can't be proved
algorithmically, within the system. That doesn't mean they can't
be proved some other way; he had to do that to prove his result.

"Self-contained" != "complete". I meant that, unlike most
subjects, you don't have to know anything about the real world to
do math, because any resemblance between math and the real world
is purely coincidental. Damned useful, but still coincidental.

--
Tom Zych
This email address will expire at some point to thwart spammers.
Permanent address: echo 'g******@cbobk.pbz' | rot13

Nov 13 '05 #127

Ben Pfaff

ru**@webmail.co.za (goose) writes:

ah ... see .. any test that tests me on anything /other/ than
C (or any programming language I may claim to know), i'd do badly
on. my experience is a rather limited problem domain.

go on. ask me about emv :-)

What's emv?
--
"Some people *are* arrogant, and others read the FAQ."
--Chris Dollin

Nov 13 '05 #128

Eric Sosman

Richard Heathfield wrote:

Okay, I'm listening. Here's the question: is the behaviour of this program
well-defined?

#include <stdio.h>
#include <ctype.h>

int main(void)
{
char buf[] = "hello world";
char *p = buf;
p[-1] = (toupper)(*p++); /* This is the trouble spot. */
printf("%s\n", buf);
return 0;
}

When I first saw this, I thought "no way". Then, after discussions with a
clc regular and much thumbing of the Standard, I began to come to the
conclusion that it might be okay (for suitably pedantic values of "okay",
obviously -- the code sucks, after all).

But I'm no longer certain, because... well, never mind! Is it well-defined?
If so, why? If not, why not?

Stick with your first impression, I'd say. Undefined
behavior: Without intervening sequence points, `p' is both
modified and read for a purpose other than to determine the
new value (6.5, paragraph 2).

The sequence point at the function call is a red herring.
It separates the `*p++' and its side-effect(s) from the body
of the function, but does not separate them from the evaluation
of the lvalue `p[-1]'.

--
Er*********@sun.com

Nov 13 '05 #129

Tom Zych wrote:

Richard Heathfield wrote:
...is the behaviour of this program well-defined?

#include <stdio.h>
#include <ctype.h>

int main(void)
{
char buf[] = "hello world";
char *p = buf;
p[-1] = (toupper)(*p++); /* This is the trouble spot. */
printf("%s\n", buf);
return 0;
}
I'm not a standard C guru (yet). My answer is, it doesn't matter,
because even if one can dig into the standard and show that this
works reliably, it's bad code.

This is a very important aspect of the answer, which no self-respecting
interviewee should ignore as a possible lifeline if they are floundering on
the actual sequence point issue.
You can't tell if it works without
being a language lawyer, and it offers no advantage over clear and
reliable code. It should be rewritten and the original coder
should be shot[1].

Yes, I think that's a fair summary. :-) My thanks to all those who
answered.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

Nov 13 '05 #130

Tom Zych

Martin Dickopp wrote:

Tom Zych <tz******@pobox.com> writes:
IIRC, Ramanujan learned from one book and figured out the rest on his
own. You can do that with math[1], because math is self-contained and
deductive.

Actually, Kurt Gödel proved that no complete axiomatic system can be free
of undecidable theorems. So not only is mathematics not self-contained and
deductive, but it couldn't even be replaced by an alternative complete
axiomatic system which is. :)

Nov 13 '05 #131

Arthur J. O'Dwyer

On Thu, 4 Sep 2003, Richard Heathfield wrote:

Denis Perelyubskiy1770880499 wrote:
On 9/4/2003 2:30 PM, Richard Heathfield:
Martin Dickopp <ex*************@zero-based.org> writes:

> Out of curiosity, would you allow the applicant to look into the C
> standard? After all, I can also consult the standard while actually
> programming. Consult the standard during programming? Frequently.
To me, this would mean one of two things: programmer who does so
either does not know C, or uses obscure constructs.

Without looking it up in any reference whatsoever, please tell me which way
round the middle two arguments of fread go.

I agree with your point, of course, but here's the mnemonic I eventually
managed to bash into my brain, and which might help some people:

Little number first, big number second.

unsigned char buffer[10];
fread(buffer, 1, 10, fp);

(Of course, this works only if you're like me and do fread/fwrite
with unsigned char buffers, rather than reading and writing whole
structs at a time. But that's not portable, so I know Richard
doesn't do it. ;-)

It works for memset, too:

Little number first, big number second.

unsigned char buffer[10];
memset(buffer, 0x00, 10);
It *doesn't* work for qsort. Now why on earth did they switch
those parameters around for qsort? Geez... but qsort has enough
other quirky bits that I end up looking it up anyway, just to
make sure I got the int (*)(const void *, const void *) correct.

HTH,
-Arthur

Nov 13 '05 #132

Eric Sosman

Richard Heathfield wrote:

Okay, I'm listening. Here's the question: is the behaviour of this program
well-defined?

#include <stdio.h>
#include <ctype.h>

int main(void)
{
char buf[] = "hello world";
char *p = buf;
p[-1] = (toupper)(*p++); /* This is the trouble spot. */
printf("%s\n", buf);
return 0;
}

When I first saw this, I thought "no way". Then, after discussions with a
clc regular and much thumbing of the Standard, I began to come to the
conclusion that it might be okay (for suitably pedantic values of "okay",
obviously -- the code sucks, after all).

But I'm no longer certain, because... well, never mind! Is it well-defined?
If so, why? If not, why not?

Nov 13 '05 #133

Tom Zych wrote:

Richard Heathfield wrote:
...is the behaviour of this program well-defined?

#include <stdio.h>
#include <ctype.h>

int main(void)
{
char buf[] = "hello world";
char *p = buf;
p[-1] = (toupper)(*p++); /* This is the trouble spot. */
printf("%s\n", buf);
return 0;
}
I'm not a standard C guru (yet). My answer is, it doesn't matter,
because even if one can dig into the standard and show that this
works reliably, it's bad code.

This is a very important aspect of the answer, which no self-respecting
interviewee should ignore as a possible lifeline if they are floundering on
the actual sequence point issue.
You can't tell if it works without
being a language lawyer, and it offers no advantage over clear and
reliable code. It should be rewritten and the original coder
should be shot[1].

Nov 13 '05 #134

Arthur J. O'Dwyer

On Thu, 4 Sep 2003, Richard Heathfield wrote:

Denis Perelyubskiy1770880499 wrote:
On 9/4/2003 2:30 PM, Richard Heathfield:
Martin Dickopp <ex*************@zero-based.org> writes:

> Out of curiosity, would you allow the applicant to look into the C
> standard? After all, I can also consult the standard while actually
> programming. Consult the standard during programming? Frequently.
To me, this would mean one of two things: programmer who does so
either does not know C, or uses obscure constructs.

Without looking it up in any reference whatsoever, please tell me which way
round the middle two arguments of fread go.

Nov 13 '05 #135

Christian Bau

In article <3F***************@sun.com>,
Eric Sosman <Er*********@sun.com> wrote:

Richard Heathfield wrote:

Okay, I'm listening. Here's the question: is the behaviour of this program
well-defined?

#include <stdio.h>
#include <ctype.h>

int main(void)
{
char buf[] = "hello world";
char *p = buf;
p[-1] = (toupper)(*p++); /* This is the trouble spot. */
printf("%s\n", buf);
return 0;
}

When I first saw this, I thought "no way". Then, after discussions with a
clc regular and much thumbing of the Standard, I began to come to the
conclusion that it might be okay (for suitably pedantic values of "okay",
obviously -- the code sucks, after all).

But I'm no longer certain, because... well, never mind! Is it well-defined?
If so, why? If not, why not?

Stick with your first impression, I'd say. Undefined
behavior: Without intervening sequence points, `p' is both
modified and read for a purpose other than to determine the
new value (6.5, paragraph 2).

Even if it were not undefined behaviour, the evaluation order is
unspecified, so you don't know whether the result would be stored int
buf [-1] or buf [0] and storing into buf [-1] is certainly not a good
idea.

Depending on your impression of the interviewer, that might be the
better answer. The interviewer might never have heard of "undefined
behavior" or "C Standard", but any interviewer should be able to
understand that this code could store into buf [-1].

Nov 13 '05 #136

Christian Bau

In article <3F***************@sun.com>,
Eric Sosman <Er*********@sun.com> wrote:

Richard Heathfield wrote:

Okay, I'm listening. Here's the question: is the behaviour of this program
well-defined?

#include <stdio.h>
#include <ctype.h>

int main(void)
{
char buf[] = "hello world";
char *p = buf;
p[-1] = (toupper)(*p++); /* This is the trouble spot. */
printf("%s\n", buf);
return 0;
}

When I first saw this, I thought "no way". Then, after discussions with a
clc regular and much thumbing of the Standard, I began to come to the
conclusion that it might be okay (for suitably pedantic values of "okay",
obviously -- the code sucks, after all).

But I'm no longer certain, because... well, never mind! Is it well-defined?
If so, why? If not, why not?

Stick with your first impression, I'd say. Undefined
behavior: Without intervening sequence points, `p' is both
modified and read for a purpose other than to determine the
new value (6.5, paragraph 2).

Nov 13 '05 #137

goose

Ben Pfaff <bl*@cs.stanford.edu> wrote in message news:<87************@pfaff.stanford.edu>...

ru**@webmail.co.za (goose) writes:
ah ... see .. any test that tests me on anything /other/ than
C (or any programming language I may claim to know), i'd do badly
on. my experience is a rather limited problem domain.

go on. ask me about emv :-)

What's emv?

(in case you were serious:-)
smartcard standard for financial transactions ...europay/mastercard/visa

goose,
by day, i'm a boring terminal developer!!! but by *night*, i'm a
boring PIC developer :-)

Nov 13 '05 #138

Randy Howard <ra**********@FOOmegapathdslBAR.net> wrote:

In article <3f55b901.871135703@news-server>, oz****@spamenot.bigpond.com
says...
Those of us who have been in the game for decades find this sort of
practice demeaning, and a good indication that it is a job we don't
want anyway. Therefore, it saves time on both persons' parts.

[..snip..]

Not all "decades of experience" programmers are equal. [...]

Quite right.

When my employer receives a CV (or 'resume' if you don't mind the lack
of accent) they provide a trivial aptitude test for the candidate to
complete. Recently I've been required to review and comment on
candidates' CVs and tests. One guy claimed over twenty years of C
experience. Judging from his test results he'd never had occasion to
use C strings or dynamically allocated memory. It is certainly possible
to write interesting programs in C using neither of those facilities.
But for twenty years? That's either stupidity or wilful perversion. I
have no particular desire to see either close up.

FWIW I actually do believe that he'd been writing C for twenty years.
That's what scares me.

--
Duncan Harvey
"One is all you need"
-- J.B., Tenacious D

Nov 13 '05 #139

Richard Heathfield <do******@address.co.uk.invalid> wrote:

Consult the standard during office debates? Well, it's rare. The usual
reaction to "let me just show you the bit..." is "Rich! Rich! We
***believe*** you, okay?!?!?!?!?!"

Anyone would think they didn't like reading technical documents. Odd,
that.

The reaction might not be odd at all.

Some people have no fear of, nor dislike of, reading technical documents
but are instead mindful of how such documents are structured and are
well aware of the perils of receiving information out of context. With
special regard to standards documents, the context /is the entire
document/. One cannot just look at a single paragraph in isolation and
declaim "this proves what I say is true". <memo to self: insert comedy
remark about religious texts and their followers> For (a silly)
example, person A might be optimising an inner loop that invoked
ispunct() a lot. They start to do bizarre things to 'optimise' away this
call to "avoid function call overhead". Person B says that it might be
the case that the implementation has already done this for them. Person
A snorts and replies, '7.3.1.11 states "The ispunct() *function* tests
[...]"'[1] and slumps back into his chair satisfied. (I admit, as
hypothetical examples go, that is not entirely convincing but I trust
that you'll see what I'm driving at.)

I can imagine scenarios where "Yes, yes. I believe you." is a
convenient and reasonably polite shorthand for, "this is indeed
interesting, but I consider it a minor point that does not affect the
outcome of the subject we were discussing, nor the project we are
working on, and it would not be a good use of our employer's time
[remember, this is an office debate] to spend a lot of time discussing
this, however engrossing it may be for us as individuals to do so, and
why can't I finish saying this run-on sentence?".

"Yes, yes. I believe you." might mean "Yes, I believe that you believe
what you say is true, but to be sure that it is actually true I'd have
to check for myself, and I don't have time/cannot be bothered/have
better things to do/don't like reading technical documents/etc.".

I can imagine a further scenario, where the person saying "Yes, yes. I
believe you." is merely an idiot.

[1] For some unknown reason Person A always cites section numbers using
octal. And may not be aware of C99.
--
Duncan Harvey
"One is all you need"
-- J.B., Tenacious D

Nov 13 '05 #140

Sheldon Simms

On Thu, 04 Sep 2003 21:30:13 +0000, Richard Heathfield wrote:

Ben Pfaff wrote:
Martin Dickopp <ex*************@zero-based.org> writes:
Out of curiosity, would you allow the applicant to look into the C
standard? After all, I can also consult the standard while actually
programming.

Out of curiosity, how many people actually do this?

Consult the standard during office debates? Well, it's rare. The usual
reaction to "let me just show you the bit..." is "Rich! Rich! We
***believe*** you, okay?!?!?!?!?!"

How nice. My experience of consulting the standard during an office
debate is less gratifying:

... so you see, according to the standard, that code has undefined
behavior. If you change this one line the code will work.

No, it didn't crash with the previous version of the compiler. The
new version must be buggy. I'm not changing my code.

Nov 13 '05 #141

Duncan Harvey wrote:

Richard Heathfield <do******@address.co.uk.invalid> wrote:
Consult the standard during office debates? Well, it's rare. The usual
reaction to "let me just show you the bit..." is "Rich! Rich! We
***believe*** you, okay?!?!?!?!?!"

Anyone would think they didn't like reading technical documents. Odd,
that.
The reaction might not be odd at all.

Some people have no fear of, nor dislike of, reading technical documents
but are instead mindful of how such documents are structured and are
well aware of the perils of receiving information out of context. With
special regard to standards documents, the context /is the entire
document/. One cannot just look at a single paragraph in isolation and
declaim "this proves what I say is true".

This is in fact absolutely key to understanding the Standard. From the
Jargon File: "A language lawyer is distinguished by the ability to show you
the five sentences scattered through a 200-plus-page manual that together
imply the answer to your question "if only you had thought to look there"."

(The only difference here being that the C Standard is rather more than 200
pages long!)

<snip>
I can imagine scenarios where "Yes, yes. I believe you." is a
convenient and reasonably polite shorthand for, "this is indeed
interesting, but I consider it a minor point that does not affect the
outcome of the subject we were discussing, nor the project we are
working on, and it would not be a good use of our employer's time
[remember, this is an office debate] to spend a lot of time discussing
this, however engrossing it may be for us as individuals to do so, and
why can't I finish saying this run-on sentence?".
That is certainly true, but alas, it's all too rarely the true motivation
behind the reaction. Fortunately, it is /sometimes/ the motivation. ;-)

"Yes, yes. I believe you." might mean "Yes, I believe that you believe
what you say is true, but to be sure that it is actually true I'd have
to check for myself, and I don't have time/cannot be bothered/have
better things to do/don't like reading technical documents/etc.".
This is rather more common, I'm afraid.

I can imagine a further scenario, where the person saying "Yes, yes. I
believe you." is merely an idiot.
And this, unfortunately, is the most common scenario of all, although I am
delighted to report that there are some very honorable exceptions (see
above).

[1] For some unknown reason Person A always cites section numbers using
octal. And may not be aware of C99.

"Octal is dead (and dead is hexadecimal)."
- Profound Quotations That Nobody Ever Actually Said, Vol III, p28.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

Nov 13 '05 #142

Richard Heathfield <do******@address.co.uk.invalid> wrote:

Duncan Harvey wrote:
Some people have no fear of, nor dislike of, reading technical documents
but are instead mindful of how such documents are structured and are
well aware of the perils of receiving information out of context. With
special regard to standards documents, the context /is the entire
document/. One cannot just look at a single paragraph in isolation and
declaim "this proves what I say is true".

This is in fact absolutely key to understanding the Standard. From the
Jargon File: "A language lawyer is distinguished by the ability to show you
the five sentences scattered through a 200-plus-page manual that together
imply the answer to your question "if only you had thought to look there"."

I suspect we agree on the essentials, but to belabour the point: either
the non-language lawyer has to read the entire standard under discussion
to be sure the LL isn't mistaken or has merely forgotten a relevant but
tucked-away subsection, or they have to, well, believe them.

I can imagine a further scenario, where the person saying "Yes, yes. I
believe you." is merely an idiot.

And this, unfortunately, is the most common scenario of all

Heh. I never said the scenarios were mutually exclusive.

[1] For some unknown reason Person A always cites section numbers using
octal. And may not be aware of C99.

"Octal is dead (and dead is hexadecimal)."

<slaps head> It took me a couple of re-reads to get that one... ;-)

--
Duncan Harvey
"One is all you need"
-- J.B., Tenacious D

Nov 13 '05 #143

Peter Nilsson

"Kevin D. Quitt" <KQ****@IEEInc.com> wrote in message
news:ub********************************@4ax.com...

On Tue, 2 Sep 2003 12:37:40 -0400, "Xenos" <do**********@spamhate.com>
wrote:
Personally, in my job hunting days, I walked out on an interviewer that
presumed to give me a test. I find the practice insulting.

[Personally, I'd love to be given that chance! Australian organisations (or
at least Canberra's) don't seem to bother with aptitude tests.]
As an occasional interviewer, I find I have to give a test. The first
question asks the applicant to rate their knowledge of C from 1 to 10,
where 1 is "What's C?" and 10 is "I'm Dennis Ritchie".

I certainly don't wish to be disrespectful, but Dennis Ritchie's role with
the Standards was consultative, and even the Committee members focused on
separate aspects of the standards. So, is Dennis necessarily at the top end
of the scale?

Another question is: does designing a language necessarily make you the top
expert at programming in that language? There are always some bright sparks
that can conjure up codings (at the very least) possibly undreamt of by the
instigator of a language. [Duff's Device would be one C example.]

I guess I think such ratings are rather nebulous and we might as well be
discussing which C programmer is the most sexiest or most likely to appear
in a movie playing themselves! :-)

--
Peter

Nov 13 '05 #144

Morris Dovey

Ben Pfaff wrote:

Martin Dickopp <ex*************@zero-based.org> writes:
Out of curiosity, would you allow the applicant to look into the C
standard? After all, I can also consult the standard while actually
programming.

Out of curiosity, how many people actually do this? I know that
I fairly often refer to it myself while programming and have even
cited bits of it in debates at the office (VMware at the moment,
Stanford later this month).

My copy of the standard resides on a biz-card sized CD-R that
travels in my brief case. I've used it frequently and have
managed to convince a few of my clients that it should be
standard issue for their libraries and/or their individual
programmers.

It's amazing how many C programmers aren't even aware that there
is a formal C language standard.

--
Morris Dovey
West Des Moines, Iowa USA
C links at http://www.iedu.com/c

Nov 13 '05 #145

Duncan Harvey wrote:

<snip>

I suspect we agree on the essentials, but to belabour the point: either
the non-language lawyer has to read the entire standard under discussion
to be sure the LL isn't mistaken or has merely forgotten a relevant but
tucked-away subsection, or they have to, well, believe them.

Right. Of course, the correct choice is to re-read the entire C Standard.
Over time, this will lead to more lawyers and fewer clients. It will not,
however, diminish the number of arguments. :-)
--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

Nov 13 '05 #146

Christian Bau

In article <1g**************************@hubris2.demon.co.uk> ,
sp**@hubris2.demon.co.uk (Duncan Harvey) wrote:

Randy Howard <ra**********@FOOmegapathdslBAR.net> wrote:
In article <3f55b901.871135703@news-server>, oz****@spamenot.bigpond.com
says...
Those of us who have been in the game for decades find this sort of
practice demeaning, and a good indication that it is a job we don't
want anyway. Therefore, it saves time on both persons' parts.
[..snip..]

Not all "decades of experience" programmers are equal. [...]

Quite right.

When my employer receives a CV (or 'resume' if you don't mind the lack
of accent) they provide a trivial aptitude test for the candidate to
complete. Recently I've been required to review and comment on
candidates' CVs and tests. One guy claimed over twenty years of C
experience. Judging from his test results he'd never had occasion to
use C strings or dynamically allocated memory. It is certainly possible
to write interesting programs in C using neither of those facilities.
But for twenty years? That's either stupidity or wilful perversion. I
have no particular desire to see either close up.

I can't remember when was the last time that I would have used C strings
and C memory allocation without any intervening layer on a major
project.

I have worked on projects where there was no need for string handling
whatsoever, and I have worked on projects where C string handling was so
inadequate for our purposes that it was useless. In both cases, no C
constant strings, no strcpy.

When you wrote "never had occasion to use dynamically allocated memory"
you probably mean "never used malloc". malloc is programming on the raw
iron. On many implementations, malloc is so broken it is basically
useless (returns a non-NULL pointer and your machine crashes if you try
to access the memory), so at the very least you have a layer in between.
FWIW I actually do believe that he'd been writing C for twenty years.
That's what scares me.

Nov 13 '05 #147

Mark Gordon

On Sat, 6 Sep 2003 22:36:51 +0100
sp**@hubris2.demon.co.uk (Duncan Harvey) wrote:

Randy Howard <ra**********@FOOmegapathdslBAR.net> wrote:
In article <3f55b901.871135703@news-server>,
oz****@spamenot.bigpond.com says...
Those of us who have been in the game for decades find this sort
of practice demeaning, and a good indication that it is a job we
don't want anyway. Therefore, it saves time on both persons'
parts.

[..snip..]

Not all "decades of experience" programmers are equal. [...]

Quite right.

When my employer receives a CV (or 'resume' if you don't mind the lack
of accent) they provide a trivial aptitude test for the candidate to
complete. Recently I've been required to review and comment on
candidates' CVs and tests. One guy claimed over twenty years of C
experience. Judging from his test results he'd never had occasion to
use C strings or dynamically allocated memory. It is certainly
possible to write interesting programs in C using neither of those
facilities. But for twenty years? That's either stupidity or wilful
perversion. I have no particular desire to see either close up.

FWIW I actually do believe that he'd been writing C for twenty years.
That's what scares me.

I spent a few years writing C code without using either dynamic memory
allocation or strings. It was embedded code which had no reason to use
strings (no display, no string inputs, nowhere to send string outputs)
and the coding standard (not written by me) did not allow dynamic memory
allocation or unbounded recursion since then you would not know how much
memory the application used and therefor whether it would work. Do you
fancy having the altimeter on an aircraft reporting an out of memory
error?

So it is entirely possible depending on what area the person was working
in.

Since then I have moved on to other fields where I regularly use strings
and dynamic memory.
--
Mark Gordon

Nov 13 '05 #148

Christian Bau <ch***********@cbau.freeserve.co.uk> wrote:

I have worked on projects where there was no need for string handling
whatsoever, and I have worked on projects where C string handling was so
inadequate for our purposes that it was useless.
I presume that to make that assessment you had to be aware of how C
strings worked?
When you wrote "never had occasion to use dynamically allocated memory"
you probably mean "never used malloc".
Possibly. I suspect the candidate in question had never programmed
equipment whose finite amount of memory affected them or their software.
malloc is programming on the raw iron.
I'd quibble about that.
On many implementations, malloc is so broken it is basically useless
(returns a non-NULL pointer and your machine crashes if you try to access
the memory), so at the very least you have a layer in between.

If your point is that you can find fault in such tests and in the test
setters, then you're absolutely right. But as has been shown elsewhere
in this thread people who have such knowledge find inventive and often
amusing ways to convey this fact. Few will merely flunk the test out of
disgust for the fools that made it. They often answer the question as
'expected' and then add an interesting, mildly sarcastic comment like
yours, quoted above. Such a comment would merit a higher score from me.

--
Duncan Harvey
"One is all you need"
-- J.B., Tenacious D

Nov 13 '05 #149