Live data from Hacker News

C Questions and Answers

kukuruku.co

71–80 of 135 posts

Re: C Questions and Answers

#71
post #4

Surprisingly accurate, author did his research. 5 is also missing a check for a NULL pointer. ;) Most of there rules are unfortunately ignored, as obscure information. The worst offender I see in wild code is 5. The second most ignored is not checking values before computation: 10, 11, 12. No.7 is very interesting, rarely violated, most programmers don't even know that is a thing or just assume the processor won't tr…

> 5 is also missing a check for a NULL pointer. ;)

Not necessarily. It could be up to the caller to ensure that the pointer isn't NULL.

Re: C Questions and Answers

#72
post #9

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.

Re: C Questions and Answers

#74
post #18
post #6

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're misunderstanding point 2. The question is to be read as: suppose an optimizing compiler does this. Has that compiler violated the standard? You don't need to know which compiler (or ever whether it's a real compiler or just one that's been made up for the question) to answer that.

Re: C Questions and Answers

#75
post #68

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.

Re: C Questions and Answers

#76
post #40
post #34

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.

I think my point is dereferencing a pointer address zero is 'undefined' but here is the rub, what happens is entirely out of the optimizer and compilers control because it depends on the context that the program is run under. One can't determine at compile time what will happen.

In fact the compiler can't make any assumptions about a pointer whose value has been hard coded.

uint8_t b = (uint8_t) 0x30; // 0x30 is the address of PORT D on an AVR Atmega8

Re: C Questions and Answers

#77
post #42

Earlier quoted context omitted.

Not sure which of my questions you're referring to. As I replied to others, saying "bar() is invoked" is not only not obvious, it's incorrect. bar() may or may not be invoked.

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.

Re: C Questions and Answers

#78

Earlier quoted context omitted.

My CS101 prof would give 50-100 line blocks of code, and hidden in them somewhere would be something like: if(condition); { some stuff } Note the semicolon after the if-statement. The tests became games of "find the semicolon or = in place of ==". Ugh.

Thankfully, your compiler probably warns about this nowadays, making such pointlessness obsolete.

And the static analysis tool you're hopefully using.

Re: C Questions and Answers

#80

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…

The article has nothing to do with optimizing compilers, nor requires knowledge of them. It merely uses optimizing compilers to illustrate what is and what isn't legal C. When there's undefined behaviour, the compiler has almost free reign, so it's important for a C developer to know what is and what isn't undefined behaviour.

My boss who is a C developer had only two answers wrong, he didn't remember you could tentatively declare a global var, and he was fooled by the comma operator inside the array index.

Post reply on HN