81–90 of 135 posts
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.
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.
Am I the only one who tried compiling :
#include #include int main(int argc, char *argv[]) { int i; int i=10; printf("i=%d\n", i); return 0; }
and got the redeclaration error I expected?
This 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.
I was so surprised by the first question that I actually tried it on my computer... Am I the only one who tried compiling : #include #include int main(int argc, char *argv[]) { int i; int i=10; printf("i=%d\n", i); return 0; } and got the redeclaration error I expected?
int i;
int i=10;
#include
int main(int argc, char *argv[]) {
printf("i=%d\n", i);
return 0;
}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…
On the topic of (overly) aggressively optimising compilers: http://blog.metaobject.com/2014/04/cc-osmartass.html ...and attempts at turning C into something a bit less programmer-hostile: https://news.ycombinator.com/item?id=8233484 My point of view is that compilers should be optimising at the level of machine instructions, not by attempting to second-guess the programmer and remove code that it thinks invokes UB. I…
Earlier quoted context omitted.
> the rest I got right including the general idea of the justifications. The majority of them can be answered correctly by someone who understands computer architecture and programming languages. E.g. #3 is about pointers which do not necessarily have only to do with C. Even JS developers implicitly deal with pointers: var v = {} // v is a pointer
That is not a pointer. In C I can perform arithmetic on a pointer. `v` is a symbol which references an object. It might be acceptable to refer to `v` as a reference if we're being sloppy. JavaScript has a DataView[1] which could be used to implement what I think is a pointer, but I do not think that most JS developers have used it. [1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
> In computer science, a pointer is a programming language object, whose value refers to (or "points to") another value stored elsewhere in the computer memory using its address. A pointer references a location in memory, and obtaining the value stored at that location is known as dereferencing the pointer.[1]
We are not being sloppy, in fact we are being extremely correct and precise. Pointers and dereferencing pointers might be implicit and automatic in Javascript but that does not change that a pointer to a value is being used, instead of the value itself.
Pointer arithmetic is not the same thing as pointers, it is merely something you might be able to do with pointers if the language you are using supports it. Rust calls its "symbols that reference objects" (what on earth?) pointers, even though you are unable to do pointer arithmetic on them (unless you drop to unsafe). C++ Smart Pointers are called as such even though you can't do arithmetic on them.
[1]: http://en.wikipedia.org/wiki/Pointer_%28computer_programming...
These examples illustrate well-intended and useful features of C, not flaws. I will explain why for each in a comment below:
Regarding the first answer: What is called a "tentative definition" is of course a "declaration".
That's not actually true in this case. The author is correct about this. When "int i = 10;" is encountered, the tentative definition behaves effectively as a declaration. If the compiler were to reach the end of the translation unit and the variable i was never defined elsewhere, however, "int i;" serves as a definition.
Earlier quoted context omitted.
That's correct, what he wanted to say is probably that there exists compilers where `bar()` is invoked. Don't be so snarky, try to understand what the author ment.
It's up to the author to show us this mythical compiler.
Odd of you to use 'mythical' when one of the most common compilers in existence does this.