Author needs to stop his anti-intellectual everyone-is-as-ignorant-as-me bullshit. I see that a lot re programming to justify a lot of silly positions. If you only know Javascript, that's great, I rather like having shiny things in my browser (I like it too much, even). That doesn't mean that C programming is obsolete; some of us know C. For example, I got #5 and #9 wrong, and the rest I got right including the general idea of the justifications. (10/12 is pretty good for someone who grew up in the Java era, but I want to get better.)
C Questions and Answers
11–20 of 135 posts
Re: C Questions and Answers
#12This reminds me of tests I took in earlier CS classes. Knowing those things are utterly useless in practice.
if(condition); {
some stuff
}
Note the semicolon after the if-statement.The tests became games of "find the semicolon or = in place of ==". Ugh.
Re: C Questions and Answers
#13Re: C Questions and Answers
#14Rarely did the quizzes provide great insight. Rather, they confirmed the benefits of keeping your code idiomatic.
Re: C Questions and Answers
#15Unsigned int >= 0 in a decrementing for-loop is a classic trap
for(i = length - 1; i but it is completely valid.
Re: C Questions and Answers
#16Assuming of course the compiler doesn't already check for all of these...
Re: C Questions and Answers
#17% cc -std=c11 -o dingens dingens.c dingens.c:6:9: error: redefinition of 'i' int i = 10; ^ dingens.c:5:9: note: previous definition is here int i; ^ 1 error generated. % cat dingens.c
#include
int main() { int i; int i = 10;
printf("hello, world\n");
return 0;
}%
Re: C Questions and Answers
#18He's discussing subtle points of the C language and yet there is no mention of which compiler he's using, whether the results might be different for different compilers, hardware platforms, and how they correlate with multiple C standards (C89, C99, C11/C1X, etc). He succeeded in convincing me that he does not know C!
There is no mention of which compiler he's using or whether the results might be different for different compilers and/or hardware platforms precisely because he's discussing the C language— not the idiosyncrasies of particular implementations. >and how they correlate with multiple C standards There's nothing going on here specific to any particular revision of ISO C (that I can see).
Did he make sure the behavior he mentioned is uniform across all ISO standards? What is his source for coming up with a certain answer to a certain piece of code? any of the standard documents? K&R book? gcc output?
As an example:
In the answer to point 2, he claims:
> ... the compiler thinks that x cannot be a null pointer ...
First of all, this gives a strong indication that he's analyzing a compiler output, a compiler that he didn't reveal in the article.
But even if we ignore that, and he truly is going by a rule that is uniform across all of K&R, C89, C99, and so on, could you or him point me to any page in the C99 standard document where it is explicitly stated along the lines that the compiler "should assume" the pointer to be not NULL after an undefined dereferencing in line (1) and hence ignore (2) and (3)? (Based on my experience, I have a very strong hunch that a standard would not enforce assumptions as a result of an undefined operation.)
If you could, you/he "may" have a point ("may", because I still have 11 other points to critique). If not, he and you clearly have no idea what you guys are talking about!
Re: C Questions and Answers
#19Already the first example is wrong. So I stopped reading. % cc -std=c11 -o dingens dingens.c dingens.c:6:9: error: redefinition of 'i' int i = 10; ^ dingens.c:5:9: note: previous definition is here int i; ^ 1 error generated. % cat dingens.c #include int main() { int i; int i = 10; printf("hello, world\n"); return 0; } %
Re: C Questions and Answers
#20Does anyone know of a tool which can automatically scan source code for these types of oversights? Assuming of course the compiler doesn't already check for all of these...