Knowledge is not absolute. Yes you can be a C expert and still not know every single little detail about C or any other language for that matter.
C Questions and Answers
31–40 of 135 posts
Re: C Questions and Answers
#32[deleted]
Re: C Questions and Answers
#33> (especially C programmers) 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…
Glad I'm not the only one who didn't find anything here that would make me think I didn't know C.
Re: C Questions and Answers
#34Earlier quoted context omitted.
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).
Too much of a coincidence! 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 analyzin…
The questions are about the C language, not any particular implementation thereof. Question 2 requires you to know that different compilers may at times legally do different things with the same piece of code. Answering question 2 does not require you to know which compiler is in use. Instead it requires you to think in the mindset of someone trying to write portable code that will work as intended with any compliant compiler.
In this case, the code is invalid because it invokes undefined behavior, and the compiler is allowed to do literally anything. The author of a portable C program is not allowed to rely on any particular behavior. I don't have any of the ISO C standards docs handy, but I'm quite certain that they all agree here. The (probably hypothetical) compiler in use here is apparently trying to apply several heuristics that are useful in other situations but fail here because there is no right answer.
In general, the C standards avoid requiring a specific behavior where choosing to require a specific behavior could hurt portability. Most C compilers make use of their leeway to interpret things in a manner that helps make bad code run and many compilers make promises beyond those required by the standard to aid in writing non-portable code.
Re: C Questions and Answers
#35Well apparently I do know C. If the author wanted to be as contrived a possible there are certainly more devious edge cases which could have been trotted out. The fact that e.g. the compiler may optimize out a NULL check after you've already dereferenced the darn thing shouldn't be surprising. Just fix your silly bug.
The problem is that (correct me if I'm wrong) an expression like "&foo->bar" counts as a dereference of foo, even though the result of the expression is simple pointer arithmetic involving foo (adding the offset of the bar member).
That's what offsetof() is for! http://man7.org/linux/man-pages/man3/offsetof.3.html
Re: C Questions and Answers
#36Since the title seems to be controversial we changed it to a neutral one.
Re: C Questions and Answers
#37Earlier quoted context omitted.
Too much of a coincidence! 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 analyzin…
>Did he make sure the behavior he mentioned is uniform across all ISO standards? I don't know. >What is his source for coming up with a certain answer to a certain piece of code? His conclusions are consistent with my understanding of the C standard. His justifications for his conclusions refer to specific rules regarding program behaviour, which suggests he's using the standard(s). >First of all, this gives a strong…
> ... MAY assume ...
and therefore his claim:
> ... Turns out, bar() is invoked even when x is the null pointer ...
is incorrect (bar may or may not be invoked) and misleading for C newbies, without any mention of the subtleties of standards and implementations. Hence my original comment.
Re: C Questions and Answers
#38Re: C Questions and Answers
#39This reminds of me of the Quiz books that were popular years ago. They'd show some code that inadvertently tripped some obscure corner of the language. Rarely did the quizzes provide great insight. Rather, they confirmed the benefits of keeping your code idiomatic.
It's pretty much what pops into my head every time I see things like these. I got most of those correct, but my universal reaction was why the hell would I write something like that in the first place?
Re: C Questions and Answers
#40Earlier quoted context omitted.
Too much of a coincidence! 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 analyzin…
The questions are about the C language, not any particular implementation thereof. Question 2 requires you to know that different compilers may at times legally do different things with the same piece of code. Answering question 2 does not require you to know which compiler is in use. Instead it requires you to think in the mindset of someone trying to write portable code that will work as intended with any compliant…
> ... the compiler is allowed to do literally anything ...
and yet he makes the claim that "bar() is invoked" which is not only incorrect (bar may or may not be invoked), but also misleading for C newbies who are actually trying to learn something by reading this article. Hence my original comment.