Proficient at C

[Nick Keighley]

I recently got my head around || as a shortcircuit operator and thought
that its "or-ness" is what made it work.

What would either inclusive or exclusive 'and' look like as a short circuit
operator?

exclusive-and was a joke.
You are aware that && is *already* a short circuit operator.

if (file_is_open && first_char_is_dollar)
resublimate_thiotoluene();

if the file isn't open the second condiction isn't
checked.

if (ptr != NULL && *ptr != 0)
copy_ptr(ptr);

is handy

 

[ediebur]

When we are looking to hire C programmers, we inevitably receive
resumes from people who claim they are "proficient at C", or something
to that extent.

For those who claim they are "proficient at C", what are some good
questions to ask them to determine if they are really "proficient at
C", as they claim?

I can think of one good question:

Which of the following definitions of main are acceptable by a
portable Standard C implementation?

A. int  main(void) { /*...*/ }
B. void main(void) { /*...*/ }
C. int  main(int argc,  char *argv[]) { /*...*/ }
D. void main(int argc,  char *argv[]) { /*...*/ }
E. int  main(int argc,  char **argv)  { /*...*/ }
F. int  main(int count, char **args)  { /*...*/ }
G. None of the above.
H. All of the above.

What other good simple, basic questions are there (e.g., don't cast
malloc)?

Thanks

I have written reams of working ( still ) C in embedded, MSDOS and
Unix environments including rewriting TCP-IP stacks, porting X-25,
virtual memory etc and I couldn't answer this without checking one of
my manuals

 

[Antoninus Twink]

All you really need to know for that is that main is an int function,
returning program success or failure. 0 is success. The other valid
returns are macros in stdlib.h and are EXIT_SUCCESS and EXIT_FAILURE.
That last is less well known, and the ignorant return non-zero
integers for failure.

You really are an incredible dick. Either that or you know better than
the huge majority of "ignorant" C programmers. Let's just pick the first
group that came to mind: the "ignorant" people who implement POSIX (why
not be concrete, and conjure up for ourselves that "ignorant" person
Chris Torek). And let's just pick the first program that came to mind:
good old grep.

EXIT STATUS

The following exit values shall be returned:

0 One or more lines were selected.
1 No lines were selected.

1 An error occurred.

Now I know you and your ilk live in a clc fantasy world where C is a
pure abstraction, unsoiled by contact with reality, but for those of us
in the real world, our C programs are often executed in shell scripts or
from other programs, and being able to distinguish between a selection
of exit/error status codes is extremely valuable.

 

[Bartc]

santosh said:



I disagree that such discussions are unproductive. You could consider void
main a sort of training slope for newbie language lawyers.

Why all this fuss about just one line of a possible million line
application?

Pretty much all you need to know about declaring main is here:

....
Interesting! I often start with
int main(void)
but then later find I need to process command-line arguments, so I
change it to
int main(int argc, char **argv).

Sometimes for quick throwaway programs, I naughtily use implicit int and
just have main().

Does anyone else have any insights to share on this important point?

Myself, other than for clc-related code, I wrote main() just once to put in
a library and haven't looked at it since. It calls a secondary entry point
start().

 

[Keith Thompson]

Why all this fuss about just one line of a possible million line
application?

[...]

Because people keep getting it wrong. This includes, unfortunately,
instructors and authors.

We'd love to be able to ignore the issue. It shouldn't be all that
difficult. But it seems to me that getting this wrong is often a
symptom of a general lack of caring about correctness. In a sense,
"void main()" is useful; it alerts us that there may be other sloppy
errors in the code.

(Yes, ``void main(void)'' can be correct for freestanding
implementations, *if* the implementation documents it. But most new C
programmers aren't using freestanding implementations.)

 

[Ed Prochak]

Good point, I once went for an interview for an embedded job where the
interviewer spent more then half the time on questions about printf and
scanf format specifiers. I hadn't used either except for simple debug
output for years before and never used them once on that job...

Well embedded programming covers such a wide range that some
disconnects are bound to happen. I know of one embedded system that
included a complete Oracle DB server inside. (Though I would wonder
about a place using scanf() in embedded programming.)

Ed

 

[jaysome]

Ian Collins said:


Right, but C is so small (or /was/ so small) that it wouldn't be unreasonable
to expect a decent C programmer to know a great deal of the language, even if
he doesn't know absolutely everything about it.


Nope, but then I'm not applying for jaysome's job, am I?

I wouldn't spend even a second interviewing you. It would be useless.

--
jay

I'd offer you the job if you just said "when".

Want to move to Oregon, USA?

 

[Serve Lau]

You can spend an entire career as a C programmer and never have to write

int main(void)

for a program that requires strict conformance to the ANSI standard.

a career starts with exercise programs....

 

[Chris H]

(Yes, ``void main(void)'' can be correct for freestanding
implementations, *if* the implementation documents it. But most new C
programmers aren't using freestanding implementations.)

That is not a safe assumption