4 ms·

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 h

by sjolsen 12y ago

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).

fizixer 12y ago
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 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!
- sjolsen 12y ago
  >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 indication that he's analyzing a compiler output, a compiler that he didn't reveal in the article. He is using the output of some compiler to illustrate the potential consequences of making the given mistake. It doesn't really matter which; the point is that it is not legal to perform lvalue-to-rvalue conversion on the result of indirecting through a null pointer. >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)? No, because the C99 standard document does not say that. What it does say is effectively that the compiler MAY assume the pointer not to be null; more generally, the compiler is allowed to assume that the program never exhibits undefined behaviour.
  - fizixer 12y ago
    > ... 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.
    - Dylan16807 12y ago
      You're misreading a descriptive statement as normative. It could have been clearer but it's not wrong.
- wtallis 12y ago
  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.
  - fizixer 12y ago
    > ... 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.
    - Gibbon1 12y ago
      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
    - wtallis 12y ago
      "bar() is invoked" is not incorrect. It's perfectly legal for a compiler to produce this result. It's just not mandatory that all compilers do so. There's nothing wrong with the question postulating that a particular compiler behaves this way; the point of the question is to remind the programmer that they have to expect and be prepared for variance between compilers when it's permitted by the standard.
- lmm 12y ago
  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.
- TheCoelacanth 12y ago
  > 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 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.

by sjolsen 12y ago

fizixer 12y ago

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 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!

sjolsen 12y ago
>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 indication that he's analyzing a compiler output, a compiler that he didn't reveal in the article. He is using the output of some compiler to illustrate the potential consequences of making the given mistake. It doesn't really matter which; the point is that it is not legal to perform lvalue-to-rvalue conversion on the result of indirecting through a null pointer. >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)? No, because the C99 standard document does not say that. What it does say is effectively that the compiler MAY assume the pointer not to be null; more generally, the compiler is allowed to assume that the program never exhibits undefined behaviour.
- fizixer 12y ago
  > ... 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.
  - Dylan16807 12y ago
    You're misreading a descriptive statement as normative. It could have been clearer but it's not wrong.
wtallis 12y ago
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.
- fizixer 12y ago
  > ... 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.
  - Gibbon1 12y ago
    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
  - wtallis 12y ago
    "bar() is invoked" is not incorrect. It's perfectly legal for a compiler to produce this result. It's just not mandatory that all compilers do so. There's nothing wrong with the question postulating that a particular compiler behaves this way; the point of the question is to remind the programmer that they have to expect and be prepared for variance between compilers when it's permitted by the standard.
lmm 12y ago
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.
TheCoelacanth 12y ago
> 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 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.