101–110 of 135 posts
Regarding the first answer: What is called a "tentative definition" is of course a "declaration".
Isn't a declaration "extern int i;"? Without the "extern", it's a definition, there's a symbol in that translation unit, etc.
Earlier quoted context omitted.
I've worked on a system where NULL mapped to valid memory. (It was an embedded system, so the memory map was custom and bizarre). Of course, insanity ensued when new programmers worked on it.
Is it the kind of system for which memset(somestruct, 0, sizeof(somestruct)) doesn't work if the struct has pointers (NULL isn't 0, so null checks will fail if one inits such struct like this)?
Earlier quoted context omitted.
I've worked on a system where NULL mapped to valid memory. (It was an embedded system, so the memory map was custom and bizarre). Of course, insanity ensued when new programmers worked on it.
Is it the kind of system for which memset(somestruct, 0, sizeof(somestruct)) doesn't work if the struct has pointers (NULL isn't 0, so null checks will fail if one inits such struct like this)?
Earlier quoted context omitted.
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 ?
I figure a lot of the time, you don't write it like that, but you get weird behavior in a much more complicated situation without obvious defects that eventually can be reduced to an example that would fit in with those quizzes.
Earlier 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…
You won't find a line that states it explicitly, but the standard does allow it.
If the pointer is null, de-referencing it invokes undefined behavior, so the program is allowed to do literally anything. That includes doing whatever it would have done if the pointer wasn't null. So the compiler is allowed to assume that the pointer is not null.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
I figure a lot of the time, you don't write it like that, but you get weird behavior in a much more complicated situation without obvious defects that eventually can be reduced to an example that would fit in with those quizzes.
I don't remember any of that, either. The worst I've ever had was a silly bug due to operator precedence. Barring some truly uninspired things (like signed integer overflow being undefined), I really think most of those are cases one shouldn't run into, not even in a much more complicated situation.
Well 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.
I've worked on a system where NULL mapped to valid memory. (It was an embedded system, so the memory map was custom and bizarre). Of course, insanity ensued when new programmers worked on it.
I think this was silly, the author clearly does know C but they are complaining about optimizing compilers which do things "behind your back" and are becoming an increasing nuisance. It's sort of a passive aggressive "I think this should be an error but it isn't an error because twisted logic that the compiler uses with respect to undefined operation." That people can teach themselves what to expect the compiler to d…
I suppose another perspective is that there are no shortage of programmers who are suffering from the Stockholm Syndrome, and having them make excuses for existing language's shortcomings are one reason it is harder to get critical mass behind less borked languages ;-)
In a similar vein to the original article, some may like to play along with: http://www.gowrikumar.com/c/index.php
...anyway, I don't see the problem exposing people to potential pitfalls. It's almost like people arguing that people shouldn't read "Expert C Programming: Deep C Secrets":
https://www.google.com/search?q=expert+c+programming+deep+c+...
...also I'll just throw this out here:
http://blog.llvm.org/2011/05/what-every-c-programmer-should-...